1:15 a.m.
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.
1:44 a.m.
2012/1/24 <p-man314(a)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
4:07 a.m.
Matthias Bolte пишет:
2012/1/24 <p-man314(a)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.
1:46 a.m.
On 01/24/2012 10:15 AM, p-man314(a)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(a)redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
4609
days inactive
4610
days old
3 comments
3 participants
participants (3)
-
Eric Blake -
Matthias Bolte -
p-man314＠mail.ru