[libvirt] using sync_manager with libvirt

[Eric Blake]

On 08/11/2010 02:53 PM, Chris Lalancette wrote:
> Unfortunately, this is not how migration works in qemu/kvm.  Using your
> nomenclature above, it's more like the following:
> 
> A guest is running on S.  A migration is then initiated, at which point D
> fires up a qemu process with a -incoming argument.  This is sort of
> a container process that will receive all of the migration data.  Crucially
> for sync-manager, though, qemu completely starts up and "attaches" to all of
> the resources (including disks) *while* qemu at S is still running.  Then it
> enters a sort of paused state (where the guest cannot run), and receives
> all of the migration data.  Once all of the migration data has been received,
> the guest on S is destroyed, and the guest on D is unpaused.  That's why Dan
> mentioned that we need two hosts to access the disk at once.

On the other hand, does D do any writes to the disk prior to the point
at which it is unpaused?  Would it work if D can be granted a read-only
lease to access to the disk for the duration of the migration data, and
then be converted over to read-write at the point when S is destroyed?

On a related vein, libguestfs provides things like 'guestfish --ro',
which is documented as a safe way to do read-only access of a disk image
in use by another VM.  That serves as another case where we want to be
able to provide read-only access to a disk while someone else holds the
read-write lease.

-- 
Eric Blake   eblake at redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 619 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20100811/7e207762/attachment-0001.sig>