Re: [libvirt] [RFC] Unify KVM kernel-space and user-space code into a single project
Hi, I am moving this thread here as this seems more appropriate. Sorry it has taken so long.. Here are 2 things that really get in the way of moving my existing installations to libvirt: * I tend to store much meta data with each VM instance: it can be things like ownership (contact details as text), monitoring info (sms phone numbers), backup (list of paths), firewall rules (custom syntax, with failover rules, etc), etc. At the moment, these extra bits of information consist of just a few optional lines of shell in each VM's definition file. I can extend these whenever I need, enumerate the VMs using the standard mechanism and trigger my specific actions as needed (firewall rules, backup or whatever). I see no way of doing this with libvirt. But please correct me if I am wrong. * not everything is exposed via libvirt: virsh can retrieve vncdisplay but libvirt (or at least the python bindings) does not. How come? This happens to be one thing I need for writing a libvirt backend for my virtual desktop software. Cheers Antoine Antoine Martin wrote:
Hi Daniel,
I'll take a look and get back to you asap.
Cheers Antoine
Daniel P. Berrange wrote:
Lets look at the ${HOME}/.qemu/qmp/ enumeration method suggested by Anthony. There's numerous ways that this can break: I don't like it either. We have libvirt for enumerating guests. We're stuck in a rut with libvirt and I think a lot of the dissatisfaction with qemu is rooted in that. It's not libvirt that's
On 03/22/2010 12:55 PM, Avi Kivity wrote: the probably, but the relationship between qemu and libvirt. +1 The obvious reason why so many people still use shell scripts rather
On 03/23/2010 02:15 AM, Anthony Liguori wrote: than libvirt is because if it just doesn't provide what they need. Every time I've looked at it (and I've been looking for a better solution for many years), it seems that it would have provided most of the things I needed, but the remaining bits were unsolvable. If you happen to remember what missing features prevented you choosing
On Tue, Mar 23, 2010 at 03:00:28AM +0700, Antoine Martin wrote: libvirt, that would be invaluable information for us, to see if there are quick wins that will help out. We got very useful feedback when recently asking people this same question
http://rwmj.wordpress.com/2010/01/07/quick-quiz-what-stops-you-from-using-li...
Allowing arbitrary passthrough of QEMU commands/args will solve some of these issues, but certainly far from solving all of them. eg guest cut+ paste, host side control of guest screen resolution, easier x509/TLS configuration for remote management, soft reboot, Windows desktop support for virt-manager, host network interface management/setup, etc
Regards, Daniel
On Thu, Apr 08, 2010 at 11:27:46PM +0100, Antoine Martin wrote:
Hi,
I am moving this thread here as this seems more appropriate. Sorry it has taken so long..
Here are 2 things that really get in the way of moving my existing installations to libvirt: * I tend to store much meta data with each VM instance: it can be things like ownership (contact details as text), monitoring info (sms phone numbers), backup (list of paths), firewall rules (custom syntax, with failover rules, etc), etc. At the moment, these extra bits of information consist of just a few optional lines of shell in each VM's definition file. I can extend these whenever I need, enumerate the VMs using the standard mechanism and trigger my specific actions as needed (firewall rules, backup or whatever). I see no way of doing this with libvirt. But please correct me if I am wrong.
One of the things I'm gonna do post 0.8.0 is allow to bundle comments and elements from a foreign namespace in the libvirt XML definition. Currently libvirt will happilly consume such a definition but all the extra are lost, basically at parse time we just extract the informations we know about, and everything else is lost. I want to provide clean ways to add metadata coming from the user and preserve them. I will probably limit the places where such metadata will be allowed: 1/ to avoid the full complexity of an XML structured editor within libvirt 2/ to not have to completely modify our configuration reading and saving code, but add this as an extra layer 3/ to be able to modify the Relax-NG schemas in a reasonnable way to allow those elements from foreign namespaces It's not a piece of cake, there will have to be some limitation and heuristics to avoid the extreme complexity and changes that a full tree preservation system would requires, but I think that should be sufficient for your kind of use case, Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
On Fri, Apr 09, 2010 at 09:49:51AM +0200, Daniel Veillard wrote:
On Thu, Apr 08, 2010 at 11:27:46PM +0100, Antoine Martin wrote:
Hi,
I am moving this thread here as this seems more appropriate. Sorry it has taken so long..
Here are 2 things that really get in the way of moving my existing installations to libvirt: * I tend to store much meta data with each VM instance: it can be things like ownership (contact details as text), monitoring info (sms phone numbers), backup (list of paths), firewall rules (custom syntax, with failover rules, etc), etc. At the moment, these extra bits of information consist of just a few optional lines of shell in each VM's definition file. I can extend these whenever I need, enumerate the VMs using the standard mechanism and trigger my specific actions as needed (firewall rules, backup or whatever). I see no way of doing this with libvirt. But please correct me if I am wrong.
One of the things I'm gonna do post 0.8.0 is allow to bundle comments and elements from a foreign namespace in the libvirt XML definition.
Currently libvirt will happilly consume such a definition but all the extra are lost, basically at parse time we just extract the informations we know about, and everything else is lost. I want to provide clean ways to add metadata coming from the user and preserve them. I will probably limit the places where such metadata will be allowed:
1/ to avoid the full complexity of an XML structured editor within libvirt 2/ to not have to completely modify our configuration reading and saving code, but add this as an extra layer 3/ to be able to modify the Relax-NG schemas in a reasonnable way to allow those elements from foreign namespaces
It's not a piece of cake, there will have to be some limitation and heuristics to avoid the extreme complexity and changes that a full tree preservation system would requires, but I think that should be sufficient for your kind of use case,
Daniel, this kind of thing would allow (for example) the addition of information to the domain XML that could be used by an event hook script? I guess by the script getting the domain XML and fishing out the extra metadata bits? Thanks, --Hugh
-- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
-- ======================================================== Hugh Brock, hbrock@redhat.com, +1-215-564-3232 Deltacloud API + Portal http://deltacloud.org Libvirt virtualization library http://libvirt.org ========================================================
On Fri, Apr 09, 2010 at 10:12:57AM -0400, Hugh O. Brock wrote:
On Fri, Apr 09, 2010 at 09:49:51AM +0200, Daniel Veillard wrote:
On Thu, Apr 08, 2010 at 11:27:46PM +0100, Antoine Martin wrote:
Hi,
I am moving this thread here as this seems more appropriate. Sorry it has taken so long..
Here are 2 things that really get in the way of moving my existing installations to libvirt: * I tend to store much meta data with each VM instance: it can be things like ownership (contact details as text), monitoring info (sms phone numbers), backup (list of paths), firewall rules (custom syntax, with failover rules, etc), etc. At the moment, these extra bits of information consist of just a few optional lines of shell in each VM's definition file. I can extend these whenever I need, enumerate the VMs using the standard mechanism and trigger my specific actions as needed (firewall rules, backup or whatever). I see no way of doing this with libvirt. But please correct me if I am wrong.
One of the things I'm gonna do post 0.8.0 is allow to bundle comments and elements from a foreign namespace in the libvirt XML definition.
Currently libvirt will happilly consume such a definition but all the extra are lost, basically at parse time we just extract the informations we know about, and everything else is lost. I want to provide clean ways to add metadata coming from the user and preserve them. I will probably limit the places where such metadata will be allowed:
1/ to avoid the full complexity of an XML structured editor within libvirt 2/ to not have to completely modify our configuration reading and saving code, but add this as an extra layer 3/ to be able to modify the Relax-NG schemas in a reasonnable way to allow those elements from foreign namespaces
It's not a piece of cake, there will have to be some limitation and heuristics to avoid the extreme complexity and changes that a full tree preservation system would requires, but I think that should be sufficient for your kind of use case,
Daniel, this kind of thing would allow (for example) the addition of information to the domain XML that could be used by an event hook script? I guess by the script getting the domain XML and fishing out the extra metadata bits?
The hook is given the full XML document associated with the guest. Thus if we add support for parsing & preserving extra namespaced elements in the XML, this data would be available to the hooks. The key is that the data must roundtrip XML -> parsed format -> XML. Currently you can pas extra data in, but it just gets ignored, so not roundtripped 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 :|
Daniel Veillard wrote:
On Thu, Apr 08, 2010 at 11:27:46PM +0100, Antoine Martin wrote:
Hi,
I am moving this thread here as this seems more appropriate. Sorry it has taken so long..
Here are 2 things that really get in the way of moving my existing installations to libvirt: * I tend to store much meta data with each VM instance: it can be things like ownership (contact details as text), monitoring info (sms phone numbers), backup (list of paths), firewall rules (custom syntax, with failover rules, etc), etc. At the moment, these extra bits of information consist of just a few optional lines of shell in each VM's definition file. I can extend these whenever I need, enumerate the VMs using the standard mechanism and trigger my specific actions as needed (firewall rules, backup or whatever). I see no way of doing this with libvirt. But please correct me if I am wrong.
One of the things I'm gonna do post 0.8.0 is allow to bundle comments and elements from a foreign namespace in the libvirt XML definition.
Currently libvirt will happilly consume such a definition but all the extra are lost, basically at parse time we just extract the informations we know about, and everything else is lost. I want to provide clean ways to add metadata coming from the user and preserve them. I will probably limit the places where such metadata will be allowed:
1/ to avoid the full complexity of an XML structured editor within libvirt 2/ to not have to completely modify our configuration reading and saving code, but add this as an extra layer 3/ to be able to modify the Relax-NG schemas in a reasonnable way to allow those elements from foreign namespaces
It's not a piece of cake, there will have to be some limitation and heuristics to avoid the extreme complexity and changes that a full tree preservation system would requires, but I think that should be sufficient for your kind of use case, Yes, I think it would. Please do contact me again when that's ready for testing and I'll give it a go.
Cheers Antoine
On Thu, Apr 08, 2010 at 11:27:46PM +0100, Antoine Martin wrote:
Hi,
I am moving this thread here as this seems more appropriate. Sorry it has taken so long..
Here are 2 things that really get in the way of moving my existing installations to libvirt: * I tend to store much meta data with each VM instance: it can be things like ownership (contact details as text), monitoring info (sms phone numbers), backup (list of paths), firewall rules (custom syntax, with failover rules, etc), etc. At the moment, these extra bits of information consist of just a few optional lines of shell in each VM's definition file. I can extend these whenever I need, enumerate the VMs using the standard mechanism and trigger my specific actions as needed (firewall rules, backup or whatever). I see no way of doing this with libvirt. But please correct me if I am wrong.
We fairly recently added a free-form text <description>...</description> element in the domain XML that you can stuff whatever you like into. The 0.8.0 release will also have support for explicitly managing firewall rules associated with a VM. It is fairly flexible, so there's a good chance that it would cope with at least some of your needs there.
* not everything is exposed via libvirt: virsh can retrieve vncdisplay but libvirt (or at least the python bindings) does not. How come? This happens to be one thing I need for writing a libvirt backend for my virtual desktop software.
The 'virsh vncdisplay' command is simply fetching the XML doc for the guest and then extracting the VNC port using a xpath expression /domain/devices/graphics[@type='vnc']/@port So for python you'd want to just get an XML handling module and do similar. 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 :|
[snip]
* not everything is exposed via libvirt: virsh can retrieve vncdisplay but libvirt (or at least the python bindings) does not. How come? This happens to be one thing I need for writing a libvirt backend for my virtual desktop software.
The 'virsh vncdisplay' command is simply fetching the XML doc for the guest and then extracting the VNC port using a xpath expression
/domain/devices/graphics[@type='vnc']/@port
So for python you'd want to just get an XML handling module and do similar. Yes, I saw that in the virsh code. Shouldn't this be part of the libvirt api proper?? Isn't it supposed to shield us from dealing with files and XML?
Cheers Antoine
On Fri, Apr 09, 2010 at 03:31:37PM +0100, Antoine Martin wrote:
[snip]
* not everything is exposed via libvirt: virsh can retrieve vncdisplay but libvirt (or at least the python bindings) does not. How come? This happens to be one thing I need for writing a libvirt backend for my virtual desktop software.
The 'virsh vncdisplay' command is simply fetching the XML doc for the guest and then extracting the VNC port using a xpath expression
/domain/devices/graphics[@type='vnc']/@port
So for python you'd want to just get an XML handling module and do similar. Yes, I saw that in the virsh code. Shouldn't this be part of the libvirt api proper?? Isn't it supposed to shield us from dealing with files and XML?
It isn't scalable to add APIs for extracting each possible piece of info from the XML. All languages have APIs for extracting data from XML using XPath (or DOM). Thus it is better to leave that flexibility to the apps rather than hardcoding APIs for it in libvirt. The XML schemas/docs are a formal part of the libvit API, so we're not trying to sheild that from apps. 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 :|
Daniel P. Berrange wrote:
On Fri, Apr 09, 2010 at 03:31:37PM +0100, Antoine Martin wrote:
[snip]
* not everything is exposed via libvirt: virsh can retrieve vncdisplay but libvirt (or at least the python bindings) does not. How come? This happens to be one thing I need for writing a libvirt backend for my virtual desktop software. The 'virsh vncdisplay' command is simply fetching the XML doc for the guest and then extracting the VNC port using a xpath expression
/domain/devices/graphics[@type='vnc']/@port
So for python you'd want to just get an XML handling module and do similar. Yes, I saw that in the virsh code. Shouldn't this be part of the libvirt api proper?? Isn't it supposed to shield us from dealing with files and XML?
It isn't scalable to add APIs for extracting each possible piece of info from the XML. All languages have APIs for extracting data from XML using XPath (or DOM). Thus it is better to leave that flexibility to the apps rather than hardcoding APIs for it in libvirt. The XML schemas/docs are a formal part of the libvit API, so we're not trying to sheild that from apps.
I was thinking of something like: domain.get_attribute("vncdisplay") Because it's a shame to have to use virsh as a wrapper (or XML file parsing) and re-do all the work that was done to get to the domain object when all your really want is just an attribute.. Cheers Antoine
Regards, Daniel
On Fri, Apr 09, 2010 at 03:53:37PM +0100, Antoine Martin wrote:
Daniel P. Berrange wrote:
On Fri, Apr 09, 2010 at 03:31:37PM +0100, Antoine Martin wrote:
[snip]
* not everything is exposed via libvirt: virsh can retrieve vncdisplay but libvirt (or at least the python bindings) does not. How come? This happens to be one thing I need for writing a libvirt backend for my virtual desktop software. The 'virsh vncdisplay' command is simply fetching the XML doc for the guest and then extracting the VNC port using a xpath expression
/domain/devices/graphics[@type='vnc']/@port
So for python you'd want to just get an XML handling module and do similar. Yes, I saw that in the virsh code. Shouldn't this be part of the libvirt api proper?? Isn't it supposed to shield us from dealing with files and XML?
It isn't scalable to add APIs for extracting each possible piece of info from the XML. All languages have APIs for extracting data from XML using XPath (or DOM). Thus it is better to leave that flexibility to the apps rather than hardcoding APIs for it in libvirt. The XML schemas/docs are a formal part of the libvit API, so we're not trying to sheild that from apps.
I was thinking of something like: domain.get_attribute("vncdisplay")
Because it's a shame to have to use virsh as a wrapper (or XML file parsing) and re-do all the work that was done to get to the domain object when all your really want is just an attribute..
You can already do that very simply in python using lxml from lxml import etree tree = etree.parse(domain.XMLDesc()) r = tree.xpath('/domain/devices/graphics[@type='vnc']/@port') So adding an API for this is only saving at best 2 lines of code, and is much less flexible in what it can do 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 :|
Daniel P. Berrange wrote:
On Fri, Apr 09, 2010 at 03:53:37PM +0100, Antoine Martin wrote:
Daniel P. Berrange wrote:
On Fri, Apr 09, 2010 at 03:31:37PM +0100, Antoine Martin wrote:
[snip]
* not everything is exposed via libvirt: virsh can retrieve vncdisplay but libvirt (or at least the python bindings) does not. How come? This happens to be one thing I need for writing a libvirt backend for my virtual desktop software. The 'virsh vncdisplay' command is simply fetching the XML doc for the guest and then extracting the VNC port using a xpath expression
/domain/devices/graphics[@type='vnc']/@port
So for python you'd want to just get an XML handling module and do similar. Yes, I saw that in the virsh code. Shouldn't this be part of the libvirt api proper?? Isn't it supposed to shield us from dealing with files and XML? It isn't scalable to add APIs for extracting each possible piece of info from the XML. All languages have APIs for extracting data from XML using XPath (or DOM). Thus it is better to leave that flexibility to the apps rather than hardcoding APIs for it in libvirt. The XML schemas/docs are a formal part of the libvit API, so we're not trying to sheild that from apps.
I was thinking of something like: domain.get_attribute("vncdisplay")
Because it's a shame to have to use virsh as a wrapper (or XML file parsing) and re-do all the work that was done to get to the domain object when all your really want is just an attribute..
You can already do that very simply in python using lxml
from lxml import etree tree = etree.parse(domain.XMLDesc()) r = tree.xpath('/domain/devices/graphics[@type='vnc']/@port') Thanks for that!
So adding an API for this is only saving at best 2 lines of code, and is much less flexible in what it can do Understood. Could this code be wrapped libvirt side with something like: domain.xpath('/domain/devices/graphics[@type='vnc']/@port') So that libvirt consumers dont need an explicit dependency on XML libraries?
Just another question that came to mind: how do I get notified when something happens to a domain? IE: how can I fire a script whenever a domain is created/added/stopped? Thanks Antoine
Daniel
[snip]
I was thinking of something like: domain.get_attribute("vncdisplay")
Because it's a shame to have to use virsh as a wrapper (or XML file parsing) and re-do all the work that was done to get to the domain object when all your really want is just an attribute..
You can already do that very simply in python using lxml
from lxml import etree tree = etree.parse(domain.XMLDesc()) r = tree.xpath('/domain/devices/graphics[@type='vnc']/@port')
Hmmm, cant seem to get that to work: libvirt_server_util.py", line 159, in detect_session_vncdisplay tree = etree.parse(domain.XMLDesc(0)) File "lxml.etree.pyx", line 2692, in lxml.etree.parse (src/lxml/lxml.etree.c:49594) File "parser.pxi", line 1500, in lxml.etree._parseDocument (src/lxml/lxml.etree.c:71364) File "parser.pxi", line 1529, in lxml.etree._parseDocumentFromURL (src/lxml/lxml.etree.c:71647) File "parser.pxi", line 1429, in lxml.etree._parseDocFromFile (src/lxml/lxml.etree.c:70742) File "parser.pxi", line 975, in lxml.etree._BaseParser._parseDocFromFile (src/lxml/lxml.etree.c:67740) File "parser.pxi", line 539, in lxml.etree._ParserContext._handleParseResultDoc (src/lxml/lxml.etree.c:63824) File "parser.pxi", line 625, in lxml.etree._handleParseResult (src/lxml/lxml.etree.c:64745) File "parser.pxi", line 563, in lxml.etree._raiseParseError (src/lxml/lxml.etree.c:64060) IOError: Error reading file '<domain type='qemu' id='1'> <name>Test</name> <uuid>bd4aa2fa-a086-e8b2-8bc5-1de3fc591958</uuid> ... </domain> ': failed to load external entity "<domain type='qemu' id='1'> <name>Test</name> ... </domain> "
On 04/09/2010 10:31 AM, Antoine Martin wrote:
[snip]
* not everything is exposed via libvirt: virsh can retrieve vncdisplay but libvirt (or at least the python bindings) does not. How come? This happens to be one thing I need for writing a libvirt backend for my virtual desktop software.
The 'virsh vncdisplay' command is simply fetching the XML doc for the guest and then extracting the VNC port using a xpath expression
/domain/devices/graphics[@type='vnc']/@port
So for python you'd want to just get an XML handling module and do similar. Yes, I saw that in the virsh code. Shouldn't this be part of the libvirt api proper?? Isn't it supposed to shield us from dealing with files and XML?
The XML description is a critical part of the libvirt API: using the API for anything more than start/stop of VMs pretty much requires reading and parsing the XML. The API does intend to hide the location of these config files though: XML is supposed to be fetched with the 'XMLDesc' or dumpxml series of commands.
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Fri, Apr 09, 2010 at 03:31:37PM +0100, Antoine Martin wrote:
[snip]
* not everything is exposed via libvirt: virsh can retrieve vncdisplay but libvirt (or at least the python bindings) does not. How come? This happens to be one thing I need for writing a libvirt backend for my virtual desktop software.
The 'virsh vncdisplay' command is simply fetching the XML doc for the guest and then extracting the VNC port using a xpath expression
/domain/devices/graphics[@type='vnc']/@port
So for python you'd want to just get an XML handling module and do similar. Yes, I saw that in the virsh code. Shouldn't this be part of the libvirt api proper?? Isn't it supposed to shield us from dealing with files and XML?
Cheers Antoine
One of the things we would like to add is a wrapper around dumpxml and the various other commands that return xml. Such a thing would take an xpath query and return a single value, rather than an XML document. It's strictly convenience for callers that don't want to bother parsing their own XML but it seems like it would make things easier for people. Can't say exactly when it will be done, but it's on the roadmap for sure. Take care, --Hugh
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
-- ======================================================== Hugh Brock, hbrock@redhat.com, +1-215-564-3232 Deltacloud API + Portal http://deltacloud.org Libvirt virtualization library http://libvirt.org ========================================================
participants (5)
-
Antoine Martin -
Cole Robinson -
Daniel P. Berrange -
Daniel Veillard -
Hugh O. Brock