Re: [libvirt] [RFC PATCH] Add proxy FS (9p) support to libvirt
On Tue, Jan 17, 2012 at 10:48:15AM +0530, M. Mohan Kumar wrote:
From: "M. Mohan Kumar" <mohan(a)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 :|