On Wednesday, January 18, 2012 03:01:47 AM Daniel P. Berrange wrote:
On Tue, Jan 17, 2012 at 10:48:15AM +0530, M. Mohan Kumar wrote:
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
I prefer above approach to determine the virtfs-proxy-helper path (ie based on qemu binary path).
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-help er
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.
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
Is it required for adding support for 9p proxy to libvirt now? Where I can get more information? -- Regards, M. Mohan Kumar