<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 19, 2014 at 1:38 AM, Daniel P. Berrange <span dir="ltr"><<a href="mailto:berrange@redhat.com" target="_blank">berrange@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5">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>
</div></div>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.</blockquote><div><br></div><div><br></div><div>Digging up this old thread because I am working on getting multi node live migration testing working (<a href="https://review.openstack.org/#/c/165182/">https://review.openstack.org/#/c/165182/</a>), and just ran into this issue (bug 1398999).</div><div><br></div><div>And I am not sure I agree with this statement. I think there is a valid case for doing block migrate with a cinder volume attached to an instance:</div><div><br></div><div><br></div><div>* Cloud isn't using a shared filesystem for ephemeral storage</div><div>* Instance is booted from an image, and a volume is attached afterwards. An admin wants to take the box the instance is running on offline for maintanince with a minimal impact to the instances running on it.</div><div><br></div><div>What is the recommended solution for that use case? If the admin disconnects and reconnects the volume themselves is there a risk of impacting whats running on the instance? etc. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
Regards,<br>
Daniel<br>
<span class=""><font color="#888888">--<br>
|: <a href="http://berrange.com" target="_blank">http://berrange.com</a>      -o-    <a href="http://www.flickr.com/photos/dberrange/" target="_blank">http://www.flickr.com/photos/dberrange/</a> :|<br>
|: <a href="http://libvirt.org" target="_blank">http://libvirt.org</a>              -o-             <a href="http://virt-manager.org" target="_blank">http://virt-manager.org</a> :|<br>
|: <a href="http://autobuild.org" target="_blank">http://autobuild.org</a>       -o-         <a href="http://search.cpan.org/~danberr/" target="_blank">http://search.cpan.org/~danberr/</a> :|<br>
|: <a href="http://entangle-photo.org" target="_blank">http://entangle-photo.org</a>       -o-       <a href="http://live.gnome.org/gtk-vnc" target="_blank">http://live.gnome.org/gtk-vnc</a> :|<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</font></span></blockquote></div><br></div></div>