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

On Oct 11, 2012, at 4:25 PM, Laine Stump <laine(a)laine.org&gt; wrote: > On 10/11/2012 05:06 PM, Kyle Mestery (kmestery) wrote: >> On Oct 1, 2012, at 10:18 AM, Kyle Mestery <kmestery(a)cisco.com&gt; 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