[libvirt] [PATCHv2 8/9] qemu: use virDomainNetGetActual*() in qemuDomainXMLToNative

[Laine Stump]

On 07/20/2011 07:34 PM, Eric Blake wrote:
> On 07/20/2011 12:21 AM, Laine Stump wrote:
>> This is the one function outside of domain_conf.c that plays around
>> with (even modifying) the internals of the virDomainNetDef, and thus
>> can't be fixed up simply by replacing direct accesses to the fields of
>> the struct with the GetActual*() access functions.
>>
>> In this case, we need to check if the defined type is "network", and
>> if it is *then* check the actual type; if the actual type is "bridge",
>> then we can at least put the bridgename in a place where it can be
>> used; otherwise (if type isn't "bridge"), we behave exactly as we used
>> to - just null out *everything*.
>> ---
>>   src/qemu/qemu_driver.c |   39 +++++++++++++++++++++++++++++++++++++--
>>   1 files changed, 37 insertions(+), 2 deletions(-)
>>
>
> ACK.  It helps when I read the context of that change:
>
>     /* 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
>      */
>
> and realized that xml-to-native is not modifying an existing 
> persistent or running domain, but operating directly on candidate xml.
>
> At the same time, it feels a bit awkward that we can't convert xml 
> directly to native cases where the command line that we use internally 
> depends on an fd number for a file that libvirt opens, rather than a 
> filename counterpart.  Is that something where we could add a new API 
> flag, or add a new qemu-specific format string (right now we only take 
> "qemu-kvm", so a new one could be "shell-script"), where we could 
> output the command line with fd numbers as-is as well as outputting 
> preliminary shell code snippets that would explain what files were 
> opened to those fd numbers (something like "exec 17>/dev/tun; qemu 
> -network fd:17")? Just thinking aloud here; I don't know that anyone 
> will have much use for this, so not a high priority.
>

Yeah, that whole bit of code did look a bit like "almost best effort" to 
translate, rather than a perfect translation. Since it's not really 
possible to give a commandline that can be run manually with 100% of the 
functionality provided when run by libvirt (with all its behind the 
scenes opening of files, creating tap devices, etc), I guess that's 
okay. If someone wants to see exactly what the command looks like when 
libvirt runs it, they can start the domain from libvirt and go look in 
the log file :-P