[libvirt] Proper behavior when "creating" a new transient domain with same name/uuid as existing persistent domain
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 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 3) upon creating the transient version, the domain/network would have its persistent flag cleared, and would thus cease to exist when destroyed. 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))
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.
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')
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) -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On Mon, Apr 21, 2014 at 09:43:21AM -0600, 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.
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.
Yes, that is what /used/ to happen. If you boot from a transient XML config, that should not impact the persistent config once the guest is shutoff again. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
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_Persist... 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.
participants (3)
-
Daniel P. Berrange -
Eric Blake -
Laine Stump