<div dir="ltr">From previous requirements discussions, I recall that:<div>- A control plan outage is unavoidable (I think everybody agrees here)</div><div>- Data plane outages should be avoided at all costs; small l3 outages deriving from the transition to the l3 agent from the network node might be allowed.</div>
<div><br></div><div>However, a L2 data plane outage on the instance NIC, albeit small, would probably still case existing TCP connections to be terminated.</div><div>I'm not sure it this can be accepted; however, if there is no way to avoid it, we should probably consider tolerating it.</div>
<div><br></div><div>It would be good to know what kind of modifications the NIC needs; perhaps no data plane downtime is needed.</div><div>Regarding libvirt version, I thinks it's ok to have no-downtime migrations only for deployments running at least a certain version of libvirt.</div>
<div><br></div><div>Salvatore</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 21 April 2014 13:18, Akihiro Motoki <span dir="ltr"><<a href="mailto:motoki@da.jp.nec.com" target="_blank">motoki@da.jp.nec.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div text="#000000" bgcolor="#FFFFFF"><div class="">
<br>
<div>(2014/04/21 18:10), Oleg Bondarev wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra"><br>
<div class="gmail_quote">On Fri, Apr 18, 2014 at 9:10 PM, Kyle Mestery <span dir="ltr">
<<a href="mailto:mestery@noironetworks.com" target="_blank">mestery@noironetworks.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>On Fri, Apr 18, 2014 at 8:52 AM, Oleg Bondarev <<a href="mailto:obondarev@mirantis.com" target="_blank">obondarev@mirantis.com</a>> wrote:<br>
> Hi all,<br>
><br>
> While investigating possible options for Nova-network to Neutron migration<br>
> I faced a couple of issues with libvirt.<br>
> One of the key requirements for the migration is that instances should stay<br>
> running and don't need restarting. In order to meet this requirement we need<br>
> to either attach new nic to the instance or update existing one to plug it<br>
> to the Neutron network.<br>
><br>
</div>
Thanks for looking into this Oleg! I just wanted to mention that if<br>
we're trying to plug a new NIC into the VM, this will likely require<br>
modifications in the guest. The new NIC will likely have a new PCI ID,<br>
MAC, etc., and thus the guest would have to switch to this. Therefor,<br>
I think it may be better to try and move the existing NIC from a nova<br>
network onto a neutron network.<br>
</blockquote>
<div><br>
</div>
<div>Yeah, I agree that modifying the existing NIC is the preferred way.</div>
</div>
</div>
</div>
</blockquote>
<br></div>
Thanks for investigating ways of migrating from nova-network to neutron.<br>
I think we need to define the levels of the migration.<br>
We can't satisfy all requirements at the same time, so we need to determine/clarify<br>
some reasonable limitations on the migration.<br>
<br>
- datapath downtime<br>
  - no downtime<br>
  - a small period of downtime<br>
  - rebooting an instnace<br>
- API and management plane downtime<br>
- Combination of the above<br>
<br>
I think modifying the existing NIC requires plug and unplug an device in some way<br>
(plug/unplug an network interface to VM? move a tap device from nova-network<br>
to neutron bridge?). It leads to a small downtime. On the other hand, adding a new<br>
interface requires a geust to deal with network migration (though it can potentially<br>
provide no downtime migration as an infra level).<br>
IMO a small downtime can be accepted in cloud use cases and it is a good start line.<br>
<br>
Thanks,<br>
Akihiro<div><div class="h5"><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</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">
<div><br>
> So what I've discovered is that attaching a new network device is only<br>
> applied<br>
> on the instance after reboot although VIR_DOMAIN_AFFECT_LIVE flag is passed<br>
> to<br>
> the libvirt call attachDeviceFlags():<br>
> <a href="https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L1412" target="_blank">
https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L1412</a><br>
> Is that expected? Are there any other options to apply new nic without<br>
> reboot?<br>
><br>
> I also tried to update existing nic of an instance by using libvirt<br>
> updateDeviceFlags() call,<br>
> but it fails with the following:<br>
> 'this function is not supported by the connection driver: cannot modify<br>
> network device configuration'<br>
> libvirt API spec (<a href="http://libvirt.org/hvsupport.html" target="_blank">http://libvirt.org/hvsupport.html</a>) shows that 0.8.0 as<br>
> minimal<br>
> qemu version for the virDomainUpdateDeviceFlags call, kvm --version on my<br>
> setup shows<br>
> 'QEMU emulator version 1.0 (qemu-kvm-1.0)'<br>
> Could someone please point what am I missing here?<br>
><br>
</div>
What does "libvirtd -V" show for the libvirt version? On my Fedora 20<br>
setup, I see the following:<br>
<br>
[kmestery@fedora-mac neutron]$ libvirtd -V<br>
libvirtd (libvirt) 1.1.3.4<br>
[kmestery@fedora-mac neutron]$<br>
</blockquote>
<div><br>
</div>
<div>On my Ubuntu 12.04 it shows:</div>
<div>
<div> $ libvirtd --version</div>
<div> libvirtd (libvirt) 0.9.8</div>
</div>
<div><br>
</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>
Thanks,<br>
Kyle<br>
<div><br>
> Any help on the above is much appreciated!<br>
><br>
> Thanks,<br>
> Oleg<br>
><br>
><br>
</div>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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>
><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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>
</blockquote>
</div>
<br>
</div>
</div>
<br>
<fieldset></fieldset> <br>
<pre>_______________________________________________
OpenStack-dev mailing list
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a>
<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>
</pre>
</blockquote>
<br>
</div></div></div>

<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>
<br></blockquote></div><br></div>