Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[release-0.57] [Bugfix]: HyperV Reenlightenment VMIs should be able to start when TSC Frequency is not exposed #8469

Conversation

kubevirt-bot
Copy link
Contributor

This is an automated cherry-pick of #8359

/assign Barakmor1

[Bugfix]: HyperV Reenlightenment VMIs should be able to start when TSC Frequency is not exposed

VMIs that use HyperV with Reenlightenment (and, implicitly, VMX, as it's
being automatically added to such VMIs) cannot migrate without
explicitly providing TSC frequency to QEMU (more info on that can be
found here: kubevirt#7986).

In Kubevirt we have a mechanism for exposing TSC frequency to the nodes
using node-labeller. However, sometimes (e.g. on some virtual nodes) the
frequency is not exposed. Therefore, VMIs with Reenlightenment shouldn't
be migratable - but they should be able to run.

Signed-off-by: Itamar Holder <iholder@redhat.com>
Before recent changes, TSC Frequency was added to the
domain XML only if "invtsc" feature was defined as
enabled at the VMI's CPU.

Now this is no longer the case, as hyperV
Reenligtenment VMs need to have TSC frequency
but don't have to enable any specific CPU feature.

Signed-off-by: Itamar Holder <iholder@redhat.com>
Signed-off-by: Itamar Holder <iholder@redhat.com>
Now the test is skipped if TSC frequency is not
exposed on the cluster.

Signed-off-by: Itamar Holder <iholder@redhat.com>
When TSC Frequency is not exposed.

Signed-off-by: Itamar Holder <iholder@redhat.com>
Signed-off-by: Itamar Holder <iholder@redhat.com>
@kubevirt-bot kubevirt-bot added release-note Denotes a PR that will be considered when it comes time to generate release notes. dco-signoff: yes Indicates the PR's author has DCO signed all their commits. labels Sep 14, 2022
Copy link
Contributor

@enp0s3 enp0s3 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/approve

@kubevirt-bot kubevirt-bot added the lgtm Indicates that a PR is ready to be merged. label Sep 14, 2022
@kubevirt-bot
Copy link
Contributor Author

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: enp0s3

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@kubevirt-bot kubevirt-bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Sep 14, 2022
@kubevirt-bot kubevirt-bot merged commit 4c08bf0 into kubevirt:release-0.57 Sep 14, 2022
@fossedihelm
Copy link
Contributor

Seems like we have no presubmit jobs to release 0.57 yet.
@dhiller @enp0s3 @brianmcarey

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. dco-signoff: yes Indicates the PR's author has DCO signed all their commits. lgtm Indicates that a PR is ready to be merged. release-note Denotes a PR that will be considered when it comes time to generate release notes. size/L
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants