[libvirt] Support to transfer OVSDB:Interface stats during Live Migration

[Laine Stump]

On 07/27/2012 01:00 PM, kiran Chunduri wrote:
> Hi Laine,
> Thanks for the response. Please find my comments inline.
> regards
> Kiran
>
> On Thu, Jul 26, 2012 at 9:39 PM, Laine Stump <laine at laine.org
> <mailto:laine at laine.org>> wrote:
>
>     On 07/26/2012 09:40 PM, kiran Chunduri wrote:
>     > Hi,
>     > I was experimenting 'live migration' with libvirt (using virsh) and
>     > observed that post migration the Interface stats in
>     'OVSDB:Interface'
>     > table are not transferred.
>
>     I'm assuming that the "OVS" part of this is openvswitch?
>
> Thats correct. Sorry, next time I will try to be more specific. 
>
>
>     > Only the values in 'external_ids'  column seem to be synced up. The
>     > libvirt version I'm using is 0.9.11.3. The virsh command used for
>     > migration is: 'virsh migrate --live fc17-vm
>     > qemu+ssh://10.23.167.219/system <http://10.23.167.219/system>
>     <http://10.23.167.219/system>'
>     >
>     > Is this the right behavior (or) Have I missed out on some option?
>
>     I don't know if it's "right", but moving state that's outside of the
>     guest itself is outside the scope of migration, at least for now.
>
>  
> Well, you are right in that the run time state of the virtual port is
> outside of the guest. But in case of Live-Migration, I think it will
> be good to have a mechanism, within libvirt, to carry the Virtual Port
> stats and any opaque run-time state along with the VM. Other than
> libvirt, I can't see who else can address this requirement.

Yes, it makes sense, but is currently outside the scope of what libvirt
handles. Fortunately, the scope is growing :-). In the past, only the
state of the virtual machine's memory + devices could be migrated.
Recently we've gained the ability for disks to be migrated as well.
You're now requesting that the state of associated ports on the switch
also be migrated.

>
>     >
>     > Can some one please guide on the approach and the source files
>     to look
>     > at If i need to add this support?
>     >
>
>     I don't really have a good idea about that. Could the information
>     related to a given guest interface be easily represented in XML within
>     the <interface> section of the guest's domain XML (which is the only
>     thing aside from an image of the guest's memory, and state of the
>     guest's emulated devices, that is transferred during a migration)? If
>     that's the case, maybe the openvswitch support in libvirt could be
>     extended to, for example, recognize some extra stuff inside of the
>     <virtualport type='openvswitch'> element when resuming a paused
>     (due to
>     migration or save) guest, and use that data to populate the db.
>
> Here, I'm not sure if XML file is the right location to store the run
> time state (for eg:stats) of virtual port. Even if it is possible to
> store in XML data form, it would mean the guest domains XML file need
> to modified before Migration (or) frequently whenever there is a
> change to this data. Ideally I would prefer, if 'libvirt' expose a
> opaque data framework, that OpenVswitch (or any other Virtual Switch)
> driver can fill in before migration and replay at the destination host.

Right, and the place that libvirt has available for that now is the
domain XML. I'm not suggesting that this should be constantly updated
all the time that the guest is running, but just that (if it can be
represented in XML in a straightforward manner) the data could be added
to the XML (when libvirt is shutting down network interfaces on the
source) as the guest is shipped over to the destination host, and read
out/applied at the other end (when it's setting up the network
interfaces on the destination). As far as opaqueness, you can be as
cryptic or revealing as you like with the data, but putting it into some
understandable format could make it more useful in other contexts, and
also avoid the problems associated with having different versions of
libvirt/openvswitch on the source and destination machines (if the data
has some structure, there is less likelyhood of unknowingly
misinterpreting it.)