[libvirt] [RFC PATCH] Add proxy FS (9p) support to libvirt

[Daniel P. Berrange]

On Tue, Jan 17, 2012 at 10:48:15AM +0530, M. Mohan Kumar wrote:
> From: "M. Mohan Kumar" <mohan at 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 :|