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

[Eric Blake]

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.

-- 
Eric Blake   eblake at redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org