Open Stack

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 <RONENKAT at 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" <berrange at redhat.com>
> To:        "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Duncan Thomas