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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list