On 10/11/2012 05:06 PM, Kyle Mestery (kmestery) wrote: > On Oct 1, 2012, at 10:18 AM, Kyle Mestery <kmestery@xxxxxxxxx> 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). 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. -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list