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@xxxxxxxxxx +1-801-349-2682
Libvirt virtualization library http://libvirt.org
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list