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

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



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 redhat com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org


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