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@laine.org <mailto:laine@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.)