[libvirt-users] how to change existing domain xml?
Hi. I'm trying to change network settings for a domain via libvirt (the driver is xenapi) with no success. According to its sources, 'virsh edit' uses virDomainGetXMLDesc(), allows to edit the received xml and then use virDomainDefineXML(). In case of xenapi driver it leads to a new vm creation (with the same name and edited settings). Looking through the list of API functions I failed to find a function like virDomainUpdateXML() that would change configuration of existing domain. Could you please suggest a way to do it? Thanks in advance.
2012/1/24 <p-man314@mail.ru>:
Hi.
I'm trying to change network settings for a domain via libvirt (the driver is xenapi) with no success.
According to its sources, 'virsh edit' uses virDomainGetXMLDesc(), allows to edit the received xml and then use virDomainDefineXML(). In case of xenapi driver it leads to a new vm creation (with the same name and edited settings).
virDomainDefineXML is the right API function. The problem is that the XenAPI driver currently has a bug here. It should check (via UUID and name) if the domain XML refers to an existing domain and update this domain or the if the given domain XML doesn't refer to an existing domain and define a new one instead. The XenAPI driver does not check this and always defines a new domain. So unfortunately you cannot edit the config of an existing domain until this bug is fixed, You might be able to workaround this bug by undefining the domain first and then redefining it. -- Matthias Bolte http://photron.blogspot.com
Matthias Bolte пишет:
2012/1/24 <p-man314@mail.ru>:
Hi.
I'm trying to change network settings for a domain via libvirt (the driver is xenapi) with no success.
According to its sources, 'virsh edit' uses virDomainGetXMLDesc(), allows to edit the received xml and then use virDomainDefineXML(). In case of xenapi driver it leads to a new vm creation (with the same name and edited settings).
virDomainDefineXML is the right API function. The problem is that the XenAPI driver currently has a bug here. It should check (via UUID and name) if the domain XML refers to an existing domain and update this domain or the if the given domain XML doesn't refer to an existing domain and define a new one instead.
The XenAPI driver does not check this and always defines a new domain.
So unfortunately you cannot edit the config of an existing domain until this bug is fixed,
Thank you for your explanations. Could you please provide a reference to this bug in the bugzilla?
You might be able to workaround this bug by undefining the domain first and then redefining it.
Unfortunately undefining and redefining destroys storage of a vm, at least with xenapi.
On 01/24/2012 10:15 AM, p-man314@mail.ru wrote:
Hi.
I'm trying to change network settings for a domain via libvirt (the driver is xenapi) with no success.
According to its sources, 'virsh edit' uses virDomainGetXMLDesc(), allows to edit the received xml and then use virDomainDefineXML(). In case of xenapi driver it leads to a new vm creation (with the same name and edited settings).
Correct, but not the full story. Question - is your guest running or inactive? Remember, there are two types of guests: persistent and transient; persistent guests can be offline (inactive) or running, while transient is always running. virDomainDefineXML() can only set the XML for an offline persistent guest (if called on a transient guest, the guest is converted over to persistent). As a result, when you use that API (such as via 'virsh edit'), you are only affecting the state of the guest for the next time it is booted, not the current running guest.
Looking through the list of API functions I failed to find a function like virDomainUpdateXML() that would change configuration of existing domain.
The reason you can't do a whole-sale replacement of a running guest's XML is that the running XML must match the current state of the running guest. However, there are many API that allow you to change a portion of the running guest's XML; although 'virsh edit' cannot expose these API, there are many other virsh commands that can do this piece-wise editing. For example, virDomainSetMemoryFlags takes a flags argument; if flags is 0, then you affect the current state of the guest (that is, a hot-plug operation on any transient or running persistent guest, or the next boot of an inactive persistent guest); if flags is VIR_DOMAIN_AFFECT_LIVE, then you affect the running guest (and error out if the guest is inactive); if flags is VIR_DOMAIN_AFFECT_CONFIG, you affect the next boot only (and error out if the guest is transient); or you can pass both flags at once. This maps back to 'virsh setmem' which has --current, --live, and --config as flag options. -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Teilnehmer (3)
-
Eric Blake -
Matthias Bolte -
p-man314＠mail.ru