Hi Eric,
thanks for an early response.
I came across an interesting feature provided by VirtualBox and which is
supported by QEMU as well (with 9p server in place) of sharing a folder
on host with the guest. As the shared folder is on same physical
machine, one need not necessarily use nfs/cifs to access the underlying
storage and should be allowed to use more efficient means to access the
same.
As QEMU provides support for accessing such shared directory with the
help of 9p server, and therefore need to be passed additional
commandline argument while starting, I wanted to test it using XML and
libvirt.
Later, came the idea to my mind why not the VM management softwares
(necessarily) have an option asking the user if he/she wants to share a
folder on host with guest, and let it create an XML accordingly which
will be passed to hypervisors and let the hypervisors decide how to do
it efficiently.
I had discussed this with Matthias Bolte on #virt and he seems convinced
to the idea as well.
So, if the idea looks good to everyone, we can have something like:
<shareddir fstype=local path='/folder/to/share' mount_tag='unique_tag'
security_model='as_applicable'>
where fstype = local filesystem
path = path to export/share
mount_tag = unique id which is visible in guest to mount this
share
security_model = passthrough/mapped/none
regards,
Harsh
On 09/13/2010 11:47 PM, Eric Blake wrote:
On 09/13/2010 11:56 AM, Harsh Bora wrote:
> Hi,
> Is there a way by which I can pass arbitrary command line args to a
> hypervisor (Qemu), and let the hypervisor decide what to do with it?
>
> I mean, is there a generic XML tag define which can be used to specify
> 'n' number of command line args which are blindly passed to hypervisor
> to process?
Yes, as of libvirt 0.8.3. It isn't yet well documented, but the list
has had several mails on the topic, such as:
https://www.redhat.com/archives/libvir-list/2010-August/msg00589.html
Meanwhile, what particular command line feature are you missing?
Ultimately, we would rather add direct libvirt XML support for all
qemu features, since that is more stable than using <qemu:commandline>
at your own risk, but without knowing what features people are trying
to add via <qemu:commandline>, we cannot prioritize which ones to
support directly in libvirt.