Re: [libvirt] XML support for arbitrary command line arguments
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