[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 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



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