[libvirt] RFC: what are the requirements to domain id
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? Nikolay
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 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. 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 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. Nikolay
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 :|
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. - Cole
On 19.05.2016 17:56, Cole Robinson wrote:
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.
Yeah, different drivers use it differently. For instance, LXC use it to report PID of container's init, QEMU use it to report sequential ID of domain, etc. Michal
participants (4)
-
Cole Robinson -
Daniel P. Berrange -
Michal Privoznik -
Nikolay Shirokovskiy