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