[libvirt] XML support for arbitrary command line arguments
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? regards, Harsh
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. -- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
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.
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'>
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 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. 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 -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
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 Tue, Sep 14, 2010 at 08:27:38PM +1000, Justin Clift wrote:
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.
You can already do that today with any HV, but its a PITA because it requires networking. You may wish to provide the filesystem to the guest OS before networking has been brought online inside the guest, or the guest may be on a completely separate LAN from the host. You don't always know just how networking has been configured in the guest and whether a firewall will block access to the network fielsystem. Pretty much all hypervisors have some kind of host<->guest filesystem that avoids use of the network for these reasons. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
If I am not wrong, we are not reinventing the wheel, in fact we are asking to support the 'invention' of an efficient means of accessing the underlying storage on same physical machine. The question is, why to take a (virtual) long route through network based protocols which will involve overheads required for network communication when we know that the required information (folder to share/mount) is on the same physical machine. Moreover, let the user decide on the 'policy' whether he wants to use NFS, CIFS or VirtFS (kind of virtualization aware filesystem) and we shall only provide the 'mechanism' to do the needful. regards, Harsh On 09/14/2010 03:57 PM, Justin Clift wrote:
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 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
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 -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
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.
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
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
On Wed, Sep 22, 2010 at 10:43:15AM +0530, Harsh Bora wrote:
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?
Opps, I remembered wrongly. I meant 'mount'. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
participants (5)
-
Daniel P. Berrange -
Eric Blake -
Harsh Bora -
Justin Clift -
Venkateswararao Jujjuri (JV)