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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

- Cole

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]