AW> I don't think that I see the immediate benefit of the lazy
AW> (migrate and fault blocks across on demand) block migration. It
AW> doubles your exposure to failure (at least) and adds overhead.
AW> The only possible example I can think of is to very temporarily
AW> offload a VM that's gone heavily CPU bound onto an unloaded host.
AW> Is there a more obviously useful situation that I'm missing?
I think the immediate benefit is mostly as a "built-in" feature to
allow migration of VMs easily between machines that do not share
access to a centralized infrastructure. Right now, if you want to do
that, you have to migrate the entire block device or file before you
can start the domain on the other side. The lazy migration allows you
to get the domain started immediately. It's probably not insanely
useful in an enterprise environment, but it would be a nice feature
for Xen to have, and I think it's possible that more enterprise
functionality could arise from developing the foundation. Even if you
had a centralized block server, you could still benefit from the
abilities, by caching blocks locally in a local block device, such as
a hard disk. The same infrastructure that provides the P2P lazy-copy
migration could be used to provide local caching, and probably more
I guess my initial comment was: I would think real enterprise people
would use iSCSI and a real SAN to provide access, instead of files on
NFS. In that case, perhaps we can give more flexibility than the NFS
solution, with better performance.
IBM Linux Technology Center
Open Hypervisor Team
Description: PGP signature
Xen-devel mailing list