On 04/21/2014 06:43 PM, Eric Blake wrote:
> On 04/21/2014 05:13 AM, Laine Stump wrote:
>> Playing around with the network driver I found that if I net-define a
>> network, then net-create using a slightly modified version of the same
>> XML file (e.g. different bridge name, but same name/uuid) the following
>> will happen:
>>
>> 1) a network of that name is started, it is persistent, and it has the
>> properties from the modified XML file (the one given to net-create).
>>
>> 2) both "net-dumpxml" and "net-dumpxml --inactive" will show the
>> modified attributes.
>>
>> 3) when I net-destroy the network, the network will still exist (since
>> it is still persistent), but will have all of the modified attributes
>> rather than the originals.
>>
>> Wanting the network driver to behave consistently with the qemu driver,
>> I did the same test with a qemu domain. I found exactly the same behavior.
>>
>> I would have expected that when I tried to create a domain (or network)
>> with the same name & UUID as an existing persistent&inactive domain (or
>> network) that one of the following two things would happen:
>>
>> 1) the operation would fail because a persistent domain/network already
>> existed
> No, we explicitly document that attempting to 'create' something that
> already exists as an inactive persistent object is merely longhand for
> 'start'ing the existing object.
[citation missing] :-)
>
>> 2) the domain/network would be started with the modified attributes, but
>> the persistent definition would still show the original attributes,
>> which would remain after destroying the transient
> Well, it's really only one object. But yes, I'd expect the persistent
> definition to remain unchanged, and that the temporary modified
> definition passed through 'create' is lost once the object is no longer
> active.
>
>> 3) upon creating the transient version, the domain/network would have
>> its persistent flag cleared, and would thus cease to exist when destroyed.
> No, we explicitly document the following possible transitions:
>
> no object -> persistent inactive ('define')
> no object -> transient running ('create')
> persistent inactive -> persistent running ('start')
> persistent inactive -> no object ('undefine')
> transient running -> persistent running ('define')
> transient running -> no object ('destroy')
> persistent running -> persistent inactive ('destroy')
> persistent running -> transient running ('undefine')
I was looking for a table like that and didn't find it in the places I
looked in the docs directory, the autogenerated API docs, or on the
wiki. The closest I found was the diagram here:
http://wiki.libvirt.org/page/VM_lifecycle#Transient_guest_domains_vs_Persistent_guest_domains
but that diagram has some extra transitions/states not mentioned above
(due to the addition of "Paused" and "Saved") and is missing others
(because it doesn't attempt to show a difference between
persistent+running and transient+running, among other things).
So where did your table come from?
(I also notice that the table you give above itself makes no mention of
the fact that "create" can be used to transition from
persistent/inactive to persistent/running :-))
>> Was the current behavior consciously arrived at, or is it just an
>> accident of circumstances? If the latter, then what should the proper
>> behavior be? (I would vote for (2))
> I also vote for behavior (2)
>
And since Dan says that it previously worked this way, I will make the
network driver (which have *never* gotten transient objects quite right)
work this way, and unless someone else beats me to it I'll fix the
regression in the qemu driver.
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list