On Tue, Jan 17, 2012 at 10:48:15AM +0530, M. Mohan Kumar wrote:
From: "M. Mohan Kumar" <mohan@in.ibm.com>
This patch *) adds new sub element <virtfs-proxy-helper> under <device> element. This sub-element is used to specify the virtfs-proxy-helper binary (part of QEMU) to be executed when proxy FS driver is used.
*) invokes proxy_helper binary specified by the <virtfs-proxy-helper> sub-element with passing one of the created socket pair descriptor and adds "-sock_fd" paramter to qemu.
Is it okay to add the sub-element "virtfs-proxy-helper" under "devices" element? Proxy helper binary is common for all 9p proxy FS devices, so it can not be placed under "filesystems" element.
Hmm, what is the version compatibility like between QEMU and the proxy helper. eg, will we be able to use a version 1.1 QEMU, with a version 1.2 virtfs-proxy-helper, or vica-verca. I'd probably expect that QEMU will always want a precisely matched virtfs-proxy-helper version. It feels to me like we should just form a proxy helper binary path, based on the path to the corresponding QEMU binary. eg, if the guest is using /home/berrange/qemu-git/bin/qemu-system-x86_64, then we should automatically use /home/berrange/qemu-git/libexec/virtfs-proxy-helper Or, alternatively, perhaps QEMU itself should be made to tell us where the helper lives. eg something like # qemu -build-config virtfs-proxy-helper-path=/home/berrange/qemu-git/libexec/virtfs-proxy-helper then libvirt would always be ensured to have the right binary to match QEMU. There is a similar need for the QEMU net device helper program In general I think one of these approachs is better than added anything else to the XML.
+/* + * Invokes the Proxy Helper with one of the socketpair as its parameter + * + */ +static int qemuInvokeProxyHelper(const char *binary, int sock, const char *path) +{ + int ret_val, status; + virCommandPtr cmd; + + cmd = virCommandNewArgList(binary, NULL); + virCommandAddArg(cmd, "-f"); + virCommandAddArgFormat(cmd, "%d", sock); + virCommandAddArg(cmd, "-p"); + virCommandAddArgFormat(cmd, "%s", path); + virCommandTransferFD(cmd, sock); + virCommandDaemonize(cmd); + ret_val = virCommandRun(cmd, &status); + if (ret_val < 0) + qemuReportError(VIR_ERR_INTERNAL_ERROR, + _("%s can't execute"), binary); + virCommandFree(cmd); + return ret_val;
This raises interesting questions wrt sVirt / SELinux integration. ie do we need to run each helper program under a dedicated SELinux context to separate them. I think we probably will need to, but I'll have to thing about this some more Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|