Standardizing the ballooning/DMC guest/host interface? about xen-api

[psafont]

The specific error comes from XAPI changing the permission to the ~/control node from n0,r$DOMID to r$DOMID
It could be argued that the whole issue derives from this permission change, maybe it should be something to address? If yes it would have an impact on this discussion too (and likely has impact on several other sw components).

Do you have any idea when these permissions changed? I can't seem to find anything in the code regarding this

squeezed's documentation explains why it doesn't create the key:

5. The Squeezed daemon
   assumes that a domain which is created with a particular
   memory/target (and startmem, to within rounding error) will
   reach a stable value of totpages before writing
   control/feature-balloon. The daemon writes this value to
   memory/memory-offset for future reference.

This might be part of the reason that the confusion happens, it can be understood that creating the key has to be done by the guest, or writing 1 to this key has to be done by the guest

shouldn't we instead deprecate this particular xenstore key and use a better-suited name, so it does not look like the feature flag it is not?

We could do that, that would mean squeezed would have to support both the old way and the new protocol for as long as there are guests that expect the precious behaviour. Have you thought of a protocol that would make sense? It might be worth thinking about the future of DMC / ballooning and design the protocol according to that

Besides this, and also related, there is an implementation issues that likely need addressing: squeezed itself reacts on the presence of the xenstore node and not to its value,

I think this behaviour should be fixed regardless of the general direction of the feature and disable ballooning when the key is 0 / false

[ydirson]

The specific error comes from XAPI changing the permission to the ~/control node from n0,r$DOMID to r$DOMID
It could be argued that the whole issue derives from this permission change, maybe it should be something to address? If yes it would have an impact on this discussion too (and likely has impact on several other sw components).

Do you have any idea when these permissions changed? I can't seem to find anything in the code regarding this

I think we can also rule out the possiblity that be that it comes from a spurious "xenstore chmod -u" (that would likely change all parents up to the xenstore root, no idea why we would ever want to do that BTW).

I asked GH to search for "/control" in the xapi-project, xenserver and xcp-ng-rpms groups with no success (far from 100% confident, I'm pretty sure it did not show me all the matching files it reported). A search for %s/control gave a much smaller set of matches but nothing interesting either. Will likely have to set a xenstore watch in early boot to deter this one.

squeezed's documentation explains why it doesn't create the key:

5. The Squeezed daemon
   assumes that a domain which is created with a particular
   memory/target (and startmem, to within rounding error) will
   reach a stable value of totpages before writing
   control/feature-balloon. The daemon writes this value to
   memory/memory-offset for future reference.

This might be part of the reason that the confusion happens, it can be understood that creating the key has to be done by the guest, or writing 1 to this key has to be done by the guest

I don't think that explains why it could not create the entry as empty, and wait for the guest to set it to 1 when ready.

shouldn't we instead deprecate this particular xenstore key and use a better-suited name, so it does not look like the feature flag it is not?

We could do that, that would mean squeezed would have to support both the old way and the new protocol for as long as there are guests that expect the precious behaviour. Have you thought of a protocol that would make sense? It might be worth thinking about the future of DMC / ballooning and design the protocol according to that

Yes - maybe it would be worth a design session in Xen Summit?

Besides this, and also related, there is an implementation issues that likely need addressing: squeezed itself reacts on the presence of the xenstore node and not to its value,

I think this behaviour should be fixed regardless of the general direction of the feature and disable ballooning when the key is 0 / false

If we assume that the only guest tools in the wild writing there today are xe-guest-utilities 6.x and 7.x (and noone created their own, that would e.g. just create the entry with empty value), then I guess yes. I'll open a separate issue.

[psafont]

I don't think that explains why it could not create the entry as empty, and wait for the guest to set it to 1 when ready.

I'm leaning towards writing 0 to it and waiting until the guest writes 1 to it. This way dom0 only writes the value on startup and then only reads from it, and domU are the ones deciding the value.

Yes - maybe it would be worth a design session in Xen Summit?

I think so, although I won't be able to make it, there will be plenty of xenserver people to talk to

[ydirson]

I don't think that explains why it could not create the entry as empty, and wait for the guest to set it to 1 when ready.

I'm leaning towards writing 0 to it and waiting until the guest writes 1 to it. This way dom0 only writes the value on startup and then only reads from it, and domU are the ones deciding the value.

The upside of initializing as empty is that we can know if the guest willfully declined (e.g. xe-daemon -B) or if it just ignored (e.g. no guest agent started), which could make its way to the XAPI layer so XO/XenCenter can show it and admins can be notified of the missing agent when relevant.

[ydirson]

Created #5027 to deal with the interpretation of feature-balloon