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.

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>' Is this the right behavior (or) Have I missed out on some option?

Can some one please guide on the approach and the source files to look at If i need to add this support?

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(a)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.

> > 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.