XSI-791/CA-343760: Backport to yangtze #777
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
VM.create will use the platformdata from the vm record if it is creating new persistent metadata, when starting the VM. If a persistent record already exists, in the case of a live migration or resume, it is left alone as usual. In the migrate/resume case case, the persistent record will have been created from stored state by a call to `set_internal_state` when importing VM metadata. If the incoming state does not contain platformdata (the upgrade case), this is copied in from the vm record. When generating the create_info record for Domain.make in `generate_create_info`, the platformdata is now taken from the persistent record rather than the vm record. Signed-off-by: Rob Hoes <[email protected]> (cherry-picked from xen-api/6721700f1ec7b36c5c20a2804661dab006fa9199)
This allows xapi to get the featureset as currently used by the VM. Signed-off-by: Rob Hoes <[email protected]> (partially cherry-picked from xen-api/f18605f250ea7a7e1d33023078cdfc75f6021828)
Levelling v2 was introduced in the Dundee release (XS 7.0). Signed-off-by: Rob Hoes <[email protected]> (cherry-picked from xen-api/f2a2b925a29fa56409c13a4a5ff2e9452c053830)
This is to replace what is currently done in xapi. A featureset update is needed if the VM lands on a host that recognises more features and therefore has a longer featureset vector. It is done simply by zero-extending the VM's set to match the length of the host's. Signed-off-by: Rob Hoes <[email protected]> (cherry-picked from xen-api/81454eacfc0efcfe53ace72a7c73234476589ab1)
The timeoffset parameter of a VM, which controls its timezone settings,
is present in the VM metadata in two places: in the build spec as well
as in the platformdata. This also drives the fact that the timeoffset is
written to two places in xenstore:
/vm/<uuid>/rtc/timeoffset
/local/domain/<domid>/platform/timeoffset
It turns out that the PV tools and/or QEMU in some way rely on both of
these paths.
When a VM starts, its timeoffset platform key is used to set the value
of both bits of metadata that are sent to xenopsd. If the timezone
inside of the VM is changed, then an event is sent back to xapi, which
updates the platform key in its xapi.
If a VM resumes, it is similar to start, but additionally the VM's
runtime metadata is sent to xenopsd as well, so the VM is resumed with
exactly the same state as before it suspended.
Since a recent change, the platformdata has been made part of xenopsd's
runtime VM metadata, and is therefore persisted across a suspend/resume
cycle or live migration. This means that the timeoffset in the
platformdata now comes from this xenopsd-level metadata rather than from
xapi's metadata.
This all would have been fine, if xenopsd were to update the timeoffset
in its persistent platformdata whenever it changes in the VM (besides
sending the event to xapi). Unfortunately, this was not the case, which
meant that, after a suspend/resume cycle, the VM's timezone reverted
back to whatever it was when the VM started, and any changes after that
are forgotten. The situation for live migration is similar.
This commit adds the missing metadata update in xenopsd.
Signed-off-by: Rob Hoes <[email protected]>
(cherry-picked from xen-api/81dd683eb65beb68207eee31a86d217deab32eef)
The generation-id of a VM is made up by xapi - specifically for Windows VMs - and xapi changes it or leaves it the same depending on the use case. One such use case is revert-from-checkpoint, where the reverted VM is expected to get a new generation-id. The generation-id is put into the plaformdata by xapi and xenopsd just writes it to xenstore when creating a domain. Because of a recent change, the platformdata is now persisted by xenopsd across suspend/resume and migration, and will therefore not take any new values that set by xapi in the VM metadata. Since a checkpoint is essentially a suspended VM, and a revert-from-checkpoint results in a VM that can subsequently be resumed, the VM now does not get a refreshed generation-id after this operation, which is a bug. To address this, the generation_id is given a dedicated field in the VM metadata for xenopsd, so that it behaves as before. Xenopsd itself then puts it into the platformdata when creating a domain. Signed-off-by: Rob Hoes <[email protected]> (partially cherry picked from commit ff3b76a7b9459a4a714996ea533d8c5710a93e73)
This is needed for the case that the type of the backend's internal state is extended in a xenopsd update, such that any running VMs have the current runtime metadata. Case in point is the recent addition of the platformdata key, where the default value (an empty map) is not sufficient. Signed-off-by: Rob Hoes <[email protected]> (cherry picked for commit xen-api/88405ce9a3e4f164ebcd222e4ce0df26b787cacd)
Signed-off-by: Rob Hoes <[email protected]>
psafont
approved these changes
May 17, 2022
lindig
approved these changes
May 17, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.