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

M. Mohan Kumar mohan at in.ibm.com
Wed Jan 18 04:56:25 UTC 2012


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




More information about the libvir-list mailing list