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

feat(xo-server): set new XAPI platform flag for nested virtualization #8395

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

MelissaFrncJrg
Copy link
Contributor

Description

Short explanation of this PR (feel free to re-use commit message)

Checklist

  • Commit
    • Title follows commit conventions
    • Reference the relevant issue (Fixes #007, See xoa-support#42, See https://...)
    • If bug fix, add Introduced by
  • Changelog
    • If visible by XOA users, add changelog entry
    • Update "Packages to release" in CHANGELOG.unreleased.md
  • PR
    • If UI changes, add screenshots
    • If not finished or not tested, open as Draft

Review process

This 2-passes review process aims to:

  • develop skills of junior reviewers
  • limit the workload for senior reviewers
  • limit the number of unnecessary changes by the author
  1. The author creates a PR.
  2. Review process:
    1. The author assigns the junior reviewer.
    2. The junior reviewer conducts their review:
      • Resolves their comments if they are addressed.
      • Adds comments if necessary or approves the PR.
    3. The junior reviewer assigns the senior reviewer.
    4. The senior reviewer conducts their review:
      • If there are no unresolved comments on the PR → merge.
      • Otherwise, we continue with 3.
  3. The author responds to comments and/or makes corrections, and we go back to 2.

Notes:

  1. The author can request a review at any time, even if the PR is still a Draft.
  2. In theory, there should not be more than one reviewer at a time.
  3. The author should not make any changes:
    • When a reviewer is assigned.
    • Between the junior and senior reviews.

@MelissaFrncJrg MelissaFrncJrg requested a review from MathieuRA March 3, 2025 09:45
@MelissaFrncJrg MelissaFrncJrg marked this pull request as ready for review March 3, 2025 13:01
Comment on lines +402 to +404
expNestedHvm: semver.satisfies(obj.hardware_platform_version, '>=3.4')
? obj.platform['nested-virt'] === 'true'
: obj.platform['exp-nested-hvm'] === true,
Copy link
Member

Choose a reason for hiding this comment

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

IMHO, expNestedHvm should only return obj.platform['exp-nested-hvm'] === ' true'' to be consistent with the XAPI and be flagged as deprecated with a small comment above explaining why, and what to use instead.
And maybe expose one property like:

isNestedVirtEnable: (isXcp83OrHigher && platformVersion >= 3.4 ? obj.platform['nested-virt'] : obj.platform['exp-nested-hvm']) === 'true' 

If you follow my suggestion, you should update the BaseXoVm type in @vates/types/xo.mts to add the new property and flag expNestedHvm as deprecated

Comment on lines +495 to +500
set: (expNestedHvm, vm) => {
const platformVersion = semver.satisfies(vm.hardware_platform_version, '>=3.4')
? 'nested-virt'
: 'exp-nested-hvm'
vm.update_platform(platformVersion, expNestedHvm ? 'true' : null)
},
Copy link
Member

Choose a reason for hiding this comment

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

Same here, I found that weird having a set expNestedHvm that in reality will updated nested-virt

Copy link
Collaborator

Choose a reason for hiding this comment

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

would it be ok to update both ?
also this could help handling VM that are migrated from 8.2 to 8.3 hosts

@@ -491,7 +492,12 @@ const methods = {
hasVendorDevice: true,

expNestedHvm: {
set: (expNestedHvm, vm) => vm.update_platform('exp-nested-hvm', expNestedHvm ? 'true' : null),
set: (expNestedHvm, vm) => {
const platformVersion = semver.satisfies(vm.hardware_platform_version, '>=3.4')
Copy link
Member

Choose a reason for hiding this comment

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

can platform_version be >= 3.4 in case of XCP-ng 8.2?

Copy link
Contributor

Choose a reason for hiding this comment

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

No it will always be 3.2.1

Copy link

Choose a reason for hiding this comment

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

3.4 is only XCP-ng 8.3 and XS 8.4

Comment on lines +15 to +16
- [VM] Updated Nested Virtualization handling to use `platform:nested-virt` for XCP-ng 8.3+ (PR [#8395](https://github.com/vatesfr/xen-orchestra/pull/8395))

Copy link
Member

Choose a reason for hiding this comment

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

This is not really user-oriented, but I don't have a better suggestion.
Maybe you can ask the XCP team what the advantage of using nested-virt is, and for example in the changelog:
use platform:nested-virt to determine if nested virtualization is enabled, because ...

Copy link
Contributor

Choose a reason for hiding this comment

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

Nested virt has never supported by XCP-ng but it kinda worked until 8.3 where some stuff in Xen broke it.
Some changes were made to gt it back to where it were before - some not supported but kinda working and considered experimental.

So for the phrasing I'd say "add back nested virt experimental features for XCP-ng >=8.3" or something like that.

Bear in mind the fix is not yet available for users though so we might want to sync for the release.

@MathieuRA MathieuRA requested a review from fbeauchamp March 3, 2025 13:24
Copy link
Collaborator

@fbeauchamp fbeauchamp left a comment

Choose a reason for hiding this comment

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

would it be ok to update both value on edit and only read the right value for the host handling the VM when checking it ?

this could help handling VM that are migrated from 8.2 to 8.3 hosts

or does the VM with the old flags need to add the new flag to handle the (future) nested virtualization ? ( @benjamreis )

@benjamreis
Copy link
Contributor

would it be ok to update both value on edit and only read the right value for the host handling the VM when checking it ?

this could help handling VM that are migrated from 8.2 to 8.3 hosts

or does the VM with the old flags need to add the new flag to handle the (future) nested virtualization ? ( @benjamreis )

I'm not sure - ping @ydirson @stormi .
I think having both flags all the time means the new one will be ignored on 8.2 and the old one will be ignored in 8.3 - but the case of 8.2 -> 8.3 upgrade is indeed a good reason to have both on 8.2 at least. What do you guys think?

@ydirson
Copy link

ydirson commented Mar 6, 2025

I do think the easy way is to set both flags unconditionally until 8.2 gets out of support, but concern was voiced that it would make the old flag live for too long (potentially forever).
OTOH setting both flags would not handle all cases either, like a VM on a 8.2 pool that had nested-virt previously activated with the old flag only, and that gets upgraded to 8.3. That kind of mismatch could possibly be detected by XO to offer the use the ability to "fix the flag", but then the same mechanism could also be used if we decide to stick with the >= 3.4 check to keep a single flag.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants