For some entitlements, it is desirable to have access to host/guest associations. For example, YYZCorp might have a product PoutineOS for Virtual Servers, which, when entitled to a virtual host machine, allows that host to have up to 4 guests using PoutineOS without consuming any regular entitlements. Candlepin could simply ensure that only 4 systems are consuming PoutineOS across the entire owner, but to be correct, we need to know that these guests are actually running on the host that has the entitlement for PoutineOS for Virtual Servers. Thus, Candlepin needs to know the host/guest associations.
A virtual guest is able to view its uuid.
A virtual host is able to view all of the uuids of its guests.
A uuid is any reasonably unique identifier that is assigned to a virtual guest. It doesn’t matter which framework defines it (it could be from libvirt, or vmware, etc), so long as both the host and guest system agree on the same value.
Guests and Hosts will only be associated under the same owner.
Guest machines will be responsible for finding their virtual uuid, and sending it to candlepin in a fact, virt.uuid. Subscription manager will take care of this for us, using libvirt/virt-what.
Hosts will be responsible for gathering a list of all of their client uuids. They must include uuids for machines in all states (running, paused, stopped) except for machines that have been destroyed or migrated.
Hosts will pass this info to candlepin in a fact, virt.guests, via a partial fact update (or a full facts update, if other facts have changed). See the server side section for more details.
There was talk of some host agent to take care of supplying this info. otherwise, rhsmcertd (or something new) will have to take care of updating this info.
Especially if there is a client side agent, and if we wish to track guest state (running vs paused), we’ll need to be able to modify the virt.guests fact without touching the rest of a consumers facts. Candlepin will expose new rest endpoints for working with a single fact:
Consumers already model a parent child relationship (see Consumer.getParent, Consumer.getChildConsumers, and the backing fields). This code is unused, however, but could be useful for ease of access to the hierarchy data. Instead of using persisted fields, candlepin should use the host/guest facts to persist parent/child relationships, and the ConsumerCurator should be responsible for populating the consumer fields based on these facts when it loads a consumer.
Consumer facts are key/value pairs, both strings. As we want to store a list in
virt.guests, we need to be careful about the format. virt.guests should be a
comma delimited list of uuids. If a uuid contains a comma, the comma must be
escaped with a
\. if a uuid contains a
\, it must be escaped with another