[libvirt] [PATCH 0/3] Transport Open vSwitch per-port data during live migration

[Kyle Mestery (kmestery)]

On Oct 11, 2012, at 4:25 PM, Laine Stump <laine at laine.org> wrote:
> On 10/11/2012 05:06 PM, Kyle Mestery (kmestery) wrote:
>> On Oct 1, 2012, at 10:18 AM, Kyle Mestery <kmestery at cisco.com> wrote:
>>> This series of commits has the end goal of allowing per-port data stored
>>> in the Open vSwitch DB to be transported during live migration. This is
>>> done by first providing a generic infrastructure for transporting network
>>> data, adding some utility functions specific to Open vSwitch, and hooking
>>> the two together.
>>> 
>>> The framework provided is generic in that other networking data could be
>>> transferred as well by simply adding in additional hooks as needed.
>>> 
>>> Kyle Mestery (3):
>>> Add the ability for the Qemu V3 migration protocol to include    
>>>   transporting network configuration. A generic framework is proposed
>>>       with this patch to allow for the transfer of opaque data.
>>> Add utility functions for Open vSwitch to both save     per-port data
>>>   before a live migration, and restore the     per-port data after a
>>>   live migration.
>>> Transport Open vSwitch per-port data during live     migration by
>>>   using the utility functions    
>>>   virNetDevOpenvswitchGetMigrateData() and    
>>>   virNetDevOpenvswitchSetMigrateData().
>>> 
>>> src/libvirt_private.syms        |   2 +
>>> src/qemu/qemu_migration.c       | 263 +++++++++++++++++++++++++++++++++++++++-
>>> src/util/virnetdevopenvswitch.c |  70 +++++++++++
>>> src/util/virnetdevopenvswitch.h |   6 +
>>> 4 files changed, 339 insertions(+), 2 deletions(-)
>> 
>> Just curious if anyone has had a chance to review this series yet? I believe I've addressed all the comments
>> I've received so far. I may need to rebase and send it out again since it's been almost 2 weeks since I sent it
>> out.
> 
> Sorry I haven't responded. Lately it's been one deadline after another
> (actually I'm working on the latest as I type).
> 
Thanks Laine!

> One thought I've had about this - since you're just taking the data
> directly from ovs-vsctl and printf-ing it into a buffer, there is a
> potential that the data could contain xml meta characters (either by
> design / on purpose, or perhaps if an attacker takes over ovs-vsctl or
> the database in some way). This could leave the system that's the target
> of the migration open to attacks based on injecting "something else"
> into the migration cookie.
> 
> Is virBufferEscapeString() enough to both guarantee nothing like that
> happens, as well as getting the exact same string at the destination? I
> *think* so, but am not sure.
> 
> Also, I'm still not so sure about having the data as an attribute when
> it could potentially been very long. DV, what's your opinion about this?
> Is it okay to have very long strings as attributes, or is it considered
> in better taste to put something that is, say, 1000 characters long as a
> separate element?
> 
> Anyway, at this point I don't think you need to rebase/resend. By the
> beginning of next week hopefully someone more wise than me about XML
> will have answered these two questions, and I can just squash in the
> minor changes and push it.

Thanks Laine! Let me know if you need anything else on my end.

Thanks,
Kyle