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.

The other interesting question to me is actually what todo in the guest with this. I think for this to be useful we really want some kind of magic in udev to automatically mount the filesystem based on the mount tag data, and in particular define some kind of rule / semantics for the mount tag otherwise every OS is going to interpret this differently making it a real pain to work with.

On 09/14/2010 07:43 PM, Daniel P. Berrange wrote: > The other interesting question to me is actually what todo in the guest > with this. I think for this to be useful we really want some kind of > magic in udev to automatically mount the filesystem based on the > mount tag data, and in particular define some kind of rule / semantics > for the mount tag otherwise every OS is going to interpret this > differently making it a real pain to work with. Is it reasonable cross platform to then "share" the selected host directories internally with the guest, using (say) NFS or CIFS? Picking those two because they cover 90% (guess) of what the guest OS's already have client software to mount, and we don't have to reinvent the wheel. ie we can add dependencies on (say) samba or such for people that want the option. ?

On 9/14/2010 2:43 AM, Daniel P. Berrange wrote: > On Tue, Sep 14, 2010 at 11:03:04AM +0530, Harsh Bora wrote: >> 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. > >> 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'> fstype may not be 'local' all the time. So in the XML description, I would propose something like fstype='filesystem type' or something like that. For now only QEMU supports local. This keyword represents all local filesystems like ext3/ext4 etc. > > We already have an XML syntax defined for filesystems using > the<filesystem> element. I've proposed an impl for QEMU using > p9fs before, but we didn't apply it yet. > > http://www.redhat.com/archives/libvir-list/2010-July/msg00458.html

From the above thread: -- Make use of the existing <filesystem> element to support plan9fs filesystem passthrough in the QEMU driver <filesystem type='mount'> <source dir='/export/to/guest'/> <target dir='/import/from/host'/> </filesystem> NB, the target is not actually a directory, it is merely a arbitrary string tag that is exported to the guest as a hint for where to mount it. -- I guess these two proposals are working towards the same goal. Just that in the second proposal we are missing security model. What does the "type" signify in the above stanza? In Harsh's proposal it represents FS type. > > Unfortunately QEMU does not have monitor commands available for the > filesystem hotplug/unplug, which would make this a far more useful > feature to users. eg so a user can open up the graphical console, > attach their home directory and access files without having to > restart the guest. I agree. VirtFS/9p on QEMU doesn't support hot-plug yet. This is on our roadmap... So we right now we can design XML flags which can accommodate hotplug/unplug feature.. or we can cross the bridge when we get there. Thanks, JV > > The other interesting question to me is actually what todo in the guest > with this. I think for this to be useful we really want some kind of > magic in udev to automatically mount the filesystem based on the > mount tag data, and in particular define some kind of rule / semantics > for the mount tag otherwise every OS is going to interpret this > differently making it a real pain to work with. > > Regards, > Daniel

On Mon, Sep 20, 2010 at 04:07:32PM -0700, Venkateswararao Jujjuri (JV) wrote: > On 9/14/2010 9:34 AM, Venkateswararao Jujjuri (JV) wrote: >> On 9/14/2010 2:43 AM, Daniel P. Berrange wrote: >>> On Tue, Sep 14, 2010 at 11:03:04AM +0530, Harsh Bora wrote: >>>> 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. >>> >>>> 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'> >> >> fstype may not be 'local' all the time. So in the XML description, I would >> propose something like >> fstype='filesystem type' or something like that. For now only QEMU >> supports local. >> This keyword represents all local filesystems like ext3/ext4 etc. >>> >>> We already have an XML syntax defined for filesystems using >>> the<filesystem> element. I've proposed an impl for QEMU using >>> p9fs before, but we didn't apply it yet. >>> >>> http://www.redhat.com/archives/libvir-list/2010-July/msg00458.html > > > Taking a closer look at the Danial's patch above, it covers almost all our > needs. > Except that the fstype and security models are hard coded. fstype is hardcoded to local only in so much as there aren't any other options in QEMU for fstype. If QEMU adds other fstype options, we'll extend<filesystem type='XXXX'> to cover them. Currently type='bind' in the XML maps to fstype=local in QEMU.

> > + virBufferAddLit(&opt, "local,security_model=mapped"); > > Any reason why it was not taken yet? I wanted to decide on best setting for security model. I think it might be better to make it use passthrough by default, since that gives better interoperability for users with matching host/guest IDs.

Daniel

On 09/22/2010 01:12 AM, Venkateswararao Jujjuri (JV) wrote: >On 9/21/2010 10:02 AM, Daniel P. Berrange wrote: >>On Mon, Sep 20, 2010 at 04:07:32PM -0700, Venkateswararao Jujjuri >>(JV) wrote: >>>On 9/14/2010 9:34 AM, Venkateswararao Jujjuri (JV) wrote: >>>>On 9/14/2010 2:43 AM, Daniel P. Berrange wrote: >>>>>On Tue, Sep 14, 2010 at 11:03:04AM +0530, Harsh Bora wrote: >>>>>>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. >>>>> >>>>>>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'> >>>> >>>>fstype may not be 'local' all the time. So in the XML description, >>>>I would >>>>propose something like >>>>fstype='filesystem type' or something like that. For now only QEMU >>>>supports local. >>>>This keyword represents all local filesystems like ext3/ext4 etc. >>>>> >>>>>We already have an XML syntax defined for filesystems using >>>>>the<filesystem> element. I've proposed an impl for QEMU using >>>>>p9fs before, but we didn't apply it yet. >>>>> >>>>>http://www.redhat.com/archives/libvir-list/2010-July/msg00458.html >>> >>> >>>Taking a closer look at the Danial's patch above, it covers almost >>>all our >>>needs. >>>Except that the fstype and security models are hard coded. >> >>fstype is hardcoded to local only in so much as there aren't >>any other options in QEMU for fstype. If QEMU adds other >>fstype options, we'll extend<filesystem type='XXXX'> to >>cover them. Currently type='bind' in the XML maps to fstype=local >>in QEMU. > Daniel, I am not able to find 'bind' in the list of possible values that <filesystem type='XXX'> supports. I am checking in docs/schemas/domain.rng, it does only have file, block, mount, template. Are you talking about something else?