Re: [libvirt] [RFC] Unify KVM kernel-space and user-space code into a single project
[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/graphi...@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 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [RFC] Unify KVM kernel-space and user-space code into a single project
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 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [RFC] Unify KVM kernel-space and user-space code into a single project
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/graphi...@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 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [RFC] Unify KVM kernel-space and user-space code into a single project
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/graphi...@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/graphi...@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/graphi...@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
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [RFC] Unify KVM kernel-space and user-space code into a single project
[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/graphi...@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'
nameTest/name
uuidbd4aa2fa-a086-e8b2-8bc5-1de3fc591958/uuid
...
/domain
': failed to load external entity domain type='qemu' id='1'
nameTest/name
...
/domain
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
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:
On Tue, Mar 23, 2010 at 03:00:28AM +0700, Antoine Martin wrote:
On 03/23/2010 02:15 AM, Anthony Liguori wrote:
On 03/22/2010 12:55 PM, Avi Kivity 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
the probably, but the relationship between qemu and libvirt.
+1
The obvious reason why so many people still use shell scripts rather
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
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-libvirt/
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
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
