Re: [Xen-devel] [PATCH] Blktap: Userspace file-based image support.(RFC)

["Andrew Warfield" <andrew.warfield@xxxxxxxxxxxx>]

(Reordering quotes from these last two replies:)

> From Stephen:
> > Conversely, for users with SANs already, whether running over iSCSI or
> > FC or whatever, block-level migration will be needed.  It's a matter of
> > being able to use existing solutions rather than mandating a new storage
> > configuration.
If you have location transparency between the VM and the storage then
NFS and SANs should both work just wine without block migration.
Aside from some minor reconfig in dom0 as part of the movement, I
don't see why you think it's going to be needed here -- I've done this
with both GNBD and iSCSI just fine.  At least insofar as I'm reading
"block-level" migration to mean "copying the blocks over to the new
physical host" -- this is how I took dan to mean this initially.

Now, in situations where the disk is fate-sharing with the CPU that
the VM is running on (e.g. you are using a local disk and want to
migrate VMs to turn the physical machine off for service), then it
seems like some form of block migration is obviously required.
Something along the lines of DRDB would seem to do a good job of
mirroring the disk to a second location in advance of migrating.

I don't think that I see the immediate benefit of the lazy (migrate
and fault blocks across on demand) block migration.  It doubles your
exposure to failure (at least) and adds overhead.  The only possible
example I can think of is to very temporarily offload a VM that's gone
heavily CPU bound onto an unloaded host.  Is there a more obviously
useful situation that I'm missing?

> > In principle, with the right software, and configuring your entire
> > infrastructure from scratch, this sort of device-based mechanism may
> > work very well.
>
> Yes. It does. Here's one we prepared earlier:
> http://www-03.ibm.com/press/us/en/pressrelease/19705.wss
I rather doubt that anyone who happens to have purchased SVC as an
image store is terribly concerned about the ability to lazily copy VM
images from one local disk to another.

a.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel