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.

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?

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.

[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?

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

> 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')

[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

-- libvir-list mailing list libvir-list(a)redhat.com https://www.redhat.com/mailman/listinfo/libvir-list