>From previous requirements discussions, I recall that: - A control plan outage is unavoidable (I think everybody agrees here) - 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.
However, a L2 data plane outage on the instance NIC, albeit small, would probably still case existing TCP connections to be terminated. I'm not sure it this can be accepted; however, if there is no way to avoid it, we should probably consider tolerating it. It would be good to know what kind of modifications the NIC needs; perhaps no data plane downtime is needed. Regarding libvirt version, I thinks it's ok to have no-downtime migrations only for deployments running at least a certain version of libvirt. Salvatore On 21 April 2014 13:18, Akihiro Motoki <mot...@da.jp.nec.com> wrote: > > (2014/04/21 18:10), Oleg Bondarev wrote: > > > On Fri, Apr 18, 2014 at 9:10 PM, Kyle Mestery > <mest...@noironetworks.com>wrote: > >> On Fri, Apr 18, 2014 at 8:52 AM, Oleg Bondarev <obonda...@mirantis.com> >> wrote: >> > Hi all, >> > >> > While investigating possible options for Nova-network to Neutron >> migration >> > I faced a couple of issues with libvirt. >> > One of the key requirements for the migration is that instances should >> stay >> > running and don't need restarting. In order to meet this requirement we >> need >> > to either attach new nic to the instance or update existing one to plug >> it >> > to the Neutron network. >> > >> Thanks for looking into this Oleg! I just wanted to mention that if >> we're trying to plug a new NIC into the VM, this will likely require >> modifications in the guest. The new NIC will likely have a new PCI ID, >> MAC, etc., and thus the guest would have to switch to this. Therefor, >> I think it may be better to try and move the existing NIC from a nova >> network onto a neutron network. >> > > Yeah, I agree that modifying the existing NIC is the preferred way. > > > Thanks for investigating ways of migrating from nova-network to neutron. > I think we need to define the levels of the migration. > We can't satisfy all requirements at the same time, so we need to > determine/clarify > some reasonable limitations on the migration. > > - datapath downtime > - no downtime > - a small period of downtime > - rebooting an instnace > - API and management plane downtime > - Combination of the above > > I think modifying the existing NIC requires plug and unplug an device in > some way > (plug/unplug an network interface to VM? move a tap device from > nova-network > to neutron bridge?). It leads to a small downtime. On the other hand, > adding a new > interface requires a geust to deal with network migration (though it can > potentially > provide no downtime migration as an infra level). > IMO a small downtime can be accepted in cloud use cases and it is a good > start line. > > Thanks, > Akihiro > > > > >> > So what I've discovered is that attaching a new network device is only >> > applied >> > on the instance after reboot although VIR_DOMAIN_AFFECT_LIVE flag is >> passed >> > to >> > the libvirt call attachDeviceFlags(): >> > >> https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L1412 >> > Is that expected? Are there any other options to apply new nic without >> > reboot? >> > >> > I also tried to update existing nic of an instance by using libvirt >> > updateDeviceFlags() call, >> > but it fails with the following: >> > 'this function is not supported by the connection driver: cannot modify >> > network device configuration' >> > libvirt API spec (http://libvirt.org/hvsupport.html) shows that 0.8.0 >> as >> > minimal >> > qemu version for the virDomainUpdateDeviceFlags call, kvm --version on >> my >> > setup shows >> > 'QEMU emulator version 1.0 (qemu-kvm-1.0)' >> > Could someone please point what am I missing here? >> > >> What does "libvirtd -V" show for the libvirt version? On my Fedora 20 >> setup, I see the following: >> >> [kmestery@fedora-mac neutron]$ libvirtd -V >> libvirtd (libvirt) 1.1.3.4 >> [kmestery@fedora-mac neutron]$ >> > > On my Ubuntu 12.04 it shows: > $ libvirtd --version > libvirtd (libvirt) 0.9.8 > > >> Thanks, >> Kyle >> >> > Any help on the above is much appreciated! >> > >> > Thanks, >> > Oleg >> > >> > >> > _______________________________________________ >> > OpenStack-dev mailing list >> > OpenStack-dev@lists.openstack.org >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > > _______________________________________________ > OpenStack-dev mailing > listOpenStack-dev@lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev