Re: Proper behavior when "creating" a new transient domain with same name/uuid as existing persistent domain

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

Attachment: signature.asc
Description: OpenPGP digital signature

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]