XCP-ng hypervisor version issues

[DagSonsteboSB]

ISSUE TYPE

• Improvement Request

COMPONENT NAME

*XCP-ng 7.x

CLOUDSTACK VERSION

• CloudStack 4.11.x

CONFIGURATION

• all

OS / ENVIRONMENT

• N/A

SUMMARY

• The host table uses the same version for XenServers and XCP-ng hosts
• As a result the guest_os_hypervisor table needs to reflect the same hypervisor version - without distinguishing XCP-ng or Xenserver
• Decision needs to be made whether to:
  ** Distinguish XCP-ng hosts with a different hypervisor version, OR
  ** Create a new hypervisor TYPE for XCP-ng
• Refer to XCP-NG 7.6 system VMs always starting as HVM when PV is expected #3086
  ** As per this ticket the hypervisor version in the host table needs to match the hypervisor version in the guest_os_hypervisor table to ensure the compute host recognises the correct Xen side template to use - which in turn determines PV or HVM. If the version doesn't match the fallback is an "other" template on Xen side, which always boots as HVM.
• Depending on the outcome of this the existing code base in https://github.com/apache/cloudstack/blob/1d05fead49f5c856257a741b07122f5633d2e359/engine/schema/src/main/resources/META-INF/db/schema-41100to41110.sql is most likely wrong, since the existing code will simply assume as version of "7.4.0" rather than "XCP-ng 7.4.0". Since XenServer was already in there with a "7.4.0" version the XCP-ng hosts would actually use this entry rather than the added new entries.

STEPS TO REPRODUCE

• N/A

EXPECTED RESULTS

• No hypervisor version issues between XCP-ng and XS

ACTUAL RESULTS

• N/A

[DagSonsteboSB]

To be discussed:

• As per original comment above - design decision needs to be made whether to keep XCP-ng as a version of XenServer or as a a new separate hypervisor alltogether.
• If a separate hypervisor then some analysis is required on how much shared codebase / split codebase this will lead to and the effort involved in managing very similar code for the two hypervisors.

[stormi]

As release manager for XCP-ng I can try to give some insight. Most codebase is shared at the moment and we maintain compatibility with XenServer. There may be a need to differentiate both hypervisors in the future, mostly depending on two factors:

• how XenServer will evolve and what parts they are going to close (current tendency: most new features are closed-source)
• new features that will be added to XCP-ng. We try to contribute them back to XenServer but we can't decide what they'll accept or not.

[DagSonsteboSB]

Thanks for the feedback @stormi - we'll take this into account going forward.

[yadvr]

Based on research until XCP-ng 7.5, I see that CloudStack only cares about the production version detail and does not care much about the product name (XenServer vs XCP-ng) therefore no redundant mappings are necessary to add xcp ng version if a similar XenServer version has been added. cc @PaulAngus @andrijapanic
I'll investigate against a live test env and if it confirms my hypothesis close the ticket.

[yadvr]

Based on #3427, XCP-ng does not require explicit version mappings. It uses the internal production name XenServer and version as found on the host.

Host seen in the UI:

Host console view:

Final note - this issue may be revisited in the future when a some difference is seen between XCP-ng and XenServer, until then CloudStack can continue to treat both the varieties as distributions of XenServer.