Open Stack

>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 <motoki at da.jp.nec.com> wrote:

>
> (2014/04/21 18:10), Oleg Bondarev wrote:
>
>
> On Fri, Apr 18, 2014 at 9:10 PM, Kyle Mestery <mestery at noironetworks.com>wrote:
>
>> On Fri, Apr 18, 2014 at 8:52 AM, Oleg Bondarev <obondarev at 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 at fedora-mac neutron]$ libvirtd -V
>> libvirtd (libvirt) 1.1.3.4
>> [kmestery at 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 at lists.openstack.org
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> _______________________________________________
> OpenStack-dev mailing listOpenStack-dev at lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140422/3c4c5d2a/attachment.html>