<p>From memory (a fuzzy memory at that!) Nova will fallback to block migration if believes shared storage is unavailable.</p>
<p>This would explain the delay, but someone who's read the code recently can confirm...</p>
<p>Thanks,<br>
Kiall</p>
<div class="gmail_quote">On Aug 8, 2012 11:08 AM, "Daniel P. Berrange" <<a href="mailto:berrange@redhat.com">berrange@redhat.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Wed, Aug 08, 2012 at 09:50:20AM +0800, Huang Zhiteng wrote:<br>
> > But to the contrary. I tested live-migrate (without block migrate)<br>
> > last night using a guest with 8GB RAM (almost fully committed) and<br>
> > lost any access/contact with the guest for over 4 minutes - it was<br>
> > paused for the duration. Not something I'd want to do to a user's<br>
> > web-server on a regular basis...<br>
><br>
> 4 minutes of pause (down time)?  That's way too long.  Even there was<br>
> crazy memory intensive workload inside the VM being migrated, the<br>
> worst case is KVM has to pause VM and transmit all 8 GB memory (all<br>
> memory are dirty, which is very rare).  If you have 1GbE link between<br>
> two host, that worst case pause period (down time) is less than 2<br>
> minutes.  My previous experience is: the down time for migrating one<br>
> idle (almost no memory access) 8GB VM via 1GbE is less than 1 second;<br>
> the down time for migrating a 8 GB VM that page got dirty really<br>
> quickly is <60 seconds.  FYI.<br>
<br>
KVM has a tunable setting for the maximum allowable live migration<br>
downtime, which IIRC defaults to something very small like 250ms.<br>
<br>
If the migration can't be completed within this downtime limit,<br>
KVM will simply never complete migration. Given that Nova does<br>
not tune this downtime setting, I don't see how you'd see 4 mins<br>
downtime unless it was not truely live migration, or there was<br>
something else broken (eg the network bridge device had a delay<br>
inserted by the STP protocol which made the VM /appear/ to be<br>
unreponsive on the network even though it was running fine).<br>
<br>
Regards,<br>
Daniel<br>
--<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>
Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
Post to     : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
More help   : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
</blockquote></div>