[libvirt] XML support for arbitrary command line arguments

[Venkateswararao Jujjuri (JV)]

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.

+    virBufferAddLit(&opt, "local,security_model=mapped");

Any reason why it was not taken yet?

Harsh, I would suggest to you take this patch as base and build on it to remove
above hard coded string.

Daniel, any suggestions on that?

Thanks,
JV

>
>  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
>