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.