Re: [libvirt] [PATCH 2/3] qemu: XMLToNative: Don't open vhostfd

On 03/13/2014 05:18 PM, Laine Stump wrote: > On 03/13/2014 01:13 PM, Cole Robinson wrote: >> Just skip the vhost command line generation, since this won't work if >> attempting to run manually. >> --- >> src/qemu/qemu_command.c | 15 +++++++++------ >> 1 file changed, 9 insertions(+), 6 deletions(-) >> >> diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c >> index 755a72a..bf7fb12 100644 >> --- a/src/qemu/qemu_command.c >> +++ b/src/qemu/qemu_command.c >> @@ -7521,7 +7521,8 @@ qemuBuildInterfaceCommandLine(virCommandPtr cmd, >> virQEMUCapsPtr qemuCaps, >> int vlan, >> int bootindex, >> - enum virNetDevVPortProfileOp vmop) >> + enum virNetDevVPortProfileOp vmop, >> + bool forXMLToArgv) > > > Ah, *now* I understand why you used that name - you're using it to > indicate multiple behavior changes that coincidentally are needed when > calling for XMLtoNative. > > Thinking... thinking... > > So a more generic way of describing this is that you want a commandline > that will be runnable standalone, not requiring/supporting all the setup > done by libvirt when it will be running the command itself. > > So maybe name it "standalone"? > Sure, I'll rename it. > Beyond that, now I'm wondering, *is* the purpose of xml-to-native to > generate something the user can run standalone? Or is it to give them a > simple way to see the exact command that libvirt would have run to start > this domain? If the former, then ACK to both this and 1/3 (but maybe > give another thought to the name for the bool). If the latter, then > maybe we shouldn't be doing this series anyway... There's a comment in qemu_driver.c XMLToNative: /* Since we're just exporting args, we can't do bridge/network/direct * setups, since libvirt will normally create TAP/macvtap devices * directly. We convert those configs into generic 'ethernet' * config and assume the user has suitable 'ifup-qemu' scripts */ Followed by some domain conf reworking to print something possibly runable, so it seems user runable is the goal. It doesn't really work in practice due to the ifup assumptions, but at least after this patch series it's as easy as s/-netdev tap/-netdev user/g to get something that boots in most cases.