Hi, all. Domain id is somewhat required feature for hypervisors: virsh list prints them by default and active/inactive distinction is based on this id value analysys. But other than -1 is reserved for inactive domains there is no further requirements for it, one can happily keep them 0 for active domains. Looks like some drivers use process pids for this purpose. Qemu driver use its own incrementing counter and domain ids endure libvirtd restart. Vz do not provide a suitable value so the question arises can some simple id implementation be good enough? By simple I mean to keep counter as long as daemon lives and do not introduce any additional persistent state. As I said before there is basically no option to not to support it. A more profound question is what is this id for? How it is supposed to be used?

On 19.05.2016 17:54, Daniel P. Berrange wrote: > On Thu, May 19, 2016 at 05:47:05PM +0300, Nikolay Shirokovskiy wrote: >> Hi, all. >> >> Domain id is somewhat required feature for hypervisors: virsh list prints >> them by default and active/inactive distinction is based on this id value >> analysys. But other than -1 is reserved for inactive domains there is no >> further requirements for it, one can happily keep them 0 for active domains. >> >> Looks like some drivers use process pids for this purpose. Qemu driver use >> its own incrementing counter and domain ids endure libvirtd restart. Vz do not >> provide a suitable value so the question arises can some simple id >> implementation be good enough? By simple I mean to keep counter as long as >> daemon lives and do not introduce any additional persistent state. As I said >> before there is basically no option to not to support it. >> >> A more profound question is what is this id for? How it is supposed to be used? > > I guess it isn't formally specified but the requirements are thus: > > * -1: all inactive domains must report this value > * 0: only permitted for control plane domain (eg Xen Domain-0 or equiv) > * > 0: must be unique for each running domain on the hypervisor connection > > There is no rule about how domain ID values must be assigned to guests, > and the value must only persist for as long as the guest is running. Next So assigning new ids after libvirtd restarts is not an option as I hoped.

> time it boots, it is free to have a different ID value, or the same value, > as desired by the hypervisor impl. Similarly you can assign then incrementally > from 0, or based on some other ID like the PID. I asked about use cases of this id having in mind that qemu implementation or those based on pid ones does not have a property of uniqness throughout system lifetime and thus probably should not be used in any automation as race conditions can have place. So looks like it is used to identify domain with fewer keystrokes in interactive command line and in this case option to regenerate id after libvirt restarts does not seems unacceptable.

On 05/19/2016 10:47 AM, Nikolay Shirokovskiy wrote: > Hi, all. > <snip> > > A more profound question is what is this id for? How it is supposed to be used? > I think most of the 'why' behind it is just that 'thats what xen does', since domain ID has been there since day 1 in libvirt, which was largely a duplicate of xen interfaces at the time.