[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] XML support for arbitrary command line arguments



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?

-Harsh
local is the only option now. But we expect it to have more options sooner if not later. It will be great if there is a way we can make it a tag/variable in this attempt. If you think it is better to deal with it later..sure we can live with that. :)



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

Sure passthrough is the most compatible option. Can you please explain
what do you mean by "best setting"? you mean the tag name?
Can we introduce new tags for security_mode and fstype(instead of overloading type=bind)?

Thanks,
JV


Daniel




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]