Dear all, I am planning to use live block migration with one VM running on local disk and also attached additional disk from iSCSI or other shared storage. When block migration, not only local VM disk is copied to the destination but also the attached additional disk from shared storage. It is not desired in this situation. I just want the local VM disk is copied. Is there anyway to do this scenario?

Does the concept of storage pool help this? I browse the source code but don't find hints right now.

On 07/10/2012 04:24 AM, Chun-Hung Chen wrote: > Dear all, > > I am planning to use live block migration with one VM running on local disk > and also attached additional disk from iSCSI or other shared storage. > When block migration, not only local VM disk is copied to the destination > but also the attached additional disk from shared storage. It is not > desired in this situation. > I just want the local VM disk is copied. Is there anyway to do this > scenario? Unfortunately, block migration during migration is an all-or-none prospect. And qemu 1.1 does not provide enough tools to do anything differently, short of creating a snapshot file where the snapshot delta is on shared storage, and then you manually copy the backing file into place on the destination, then migrate without copying storage; but there is no way to coalesce things back into one file once you take the snapshot. Qemu 1.2 will be adding some new features that allow for block storage migration as well as live commits (coalescing a delta snapshot file back into its backing file) which can then be exposed through libvirt to provide more functionality into what you want to do. > Does the concept of storage pool help this? I browse the source > code but don't find hints right now. A storage pool lets you inform libvirt where your shared storage lives, but does not help with the aspect of whether live storage migration is possible in the underlying qemu. -- Eric Blake eblake(a)redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org