On Fri, May 20, 2016 at 10:00:16AM +0300, Nikolay Shirokovskiy wrote: > > > 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. Technically that would not be in keeping with our stability definition. In practice it probably wouldn't matter, since any sane app these days really ought to be doing UUID based tracking. > > 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. NB The ID does not have to be stable & unique for the host system lifetime. It only has to be stable & unique for the duration of the current guest boot lifetime. 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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list