I think here there are two different processes making us of libvirt block migration:
1) Instance migration, which should not do anything with cinder volumes 2) Cinder live migration between backends, which is what I think Ronen Kat is referring to On 19 June 2014 11:06, Ronen Kat <ronen...@il.ibm.com> wrote: > The use-case for block migration in Libvirt/QEMU is to allow migration > between two different back-ends. > This is basically a host based volume migration, ESXi has a similar > functionality (storage vMotion), but probably not enabled with OpenStack. > Btw, if the Cinder volume driver can migrate the volume by itself, the > Libvirt/QEMU is not called upon, but if it can't (different vendor boxes > don't talk to each other), then Cinder asks Nova to help move the data... > > If you are missing this host based process you are basically have a "data > lock-in" on a specific back-end - the use case could be storage evacuation, > or just moving the data to a different box. > > Ronen, > > > > From: "Daniel P. Berrange" <berra...@redhat.com> > To: "OpenStack Development Mailing List (not for usage questions)" > <openstack-dev@lists.openstack.org>, > Date: 19/06/2014 11:42 AM > Subject: Re: [openstack-dev] [nova][libvirt] Block migrations and > Cinder volumes > ________________________________ > > > > On Wed, Jun 18, 2014 at 11:09:33PM -0700, Rafi Khardalian wrote: >> I am concerned about how block migration functions when Cinder volumes are >> attached to an instance being migrated. We noticed some unexpected >> behavior recently, whereby attached generic NFS-based volumes would become >> entirely unsparse over the course of a migration. After spending some >> time >> reviewing the code paths in Nova, I'm more concerned that this was >> actually >> a minor symptom of a much more significant issue. >> >> For those unfamiliar, NFS-based volumes are simply RAW files residing on >> an >> NFS mount. From Libvirt's perspective, these volumes look no different >> than root or ephemeral disks. We are currently not filtering out volumes >> whatsoever when making the request into Libvirt to perform the migration. >> Libvirt simply receives an additional flag (VIR_MIGRATE_NON_SHARED_INC) >> when a block migration is requested, which applied to the entire migration >> process, not differentiated on a per-disk basis. Numerous guards within >> Nova to prevent a block based migration from being allowed if the instance >> disks exist on the destination; yet volumes remain attached and within the >> defined XML during a block migration. >> >> Unless Libvirt has a lot more logic around this than I am lead to believe, >> this seems like a recipe for corruption. It seems as though this would >> also impact any type of volume attached to an instance (iSCSI, RBD, etc.), >> NFS just happens to be what we were testing. If I am wrong and someone >> can >> correct my understanding, I would really appreciate it. Otherwise, I'm >> surprised we haven't had more reports of issues when block migrations are >> used in conjunction with any attached volumes. > > Libvirt/QEMU has no special logic. When told to block-migrate, it will do > so for *all* disks attached to the VM in read-write-exclusive mode. It will > only skip those marked read-only or read-write-shared mode. Even that > distinction is somewhat dubious and so not reliably what you would want. > > It seems like we should just disallow block migrate when any cinder volumes > are attached to the VM, since there is never any valid use case for doing > block migrate from a cinder volume to itself. > > Regards, > Daniel > -- > |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ > :| > |: http://libvirt.org -o- http://virt-manager.org > :| > |: http://autobuild.org -o- http://search.cpan.org/~danberr/ > :| > |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc > :| > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Duncan Thomas _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
