CA-376372: Block installations when VT support is not available

[GeraldEV]

The host installer currently checks for hardware virtualisation support,
if it isn't found it displays a warning but allows users to continue
with the installation anyway.
After installation, Dom0 will be able to start but no other virtual
machines (neither Linux nor Windows) will be able to start. This leaves
the host in a state which is difficult to debug for support, especially
if the user does not mention the warnings during installation (or
simply ignored them).

--
It would be most frustrating for a user to step through any amount of
the installer only to discover that the installation was doomed from the
beginning (especially if we already knew it was going to fail).

Put the blocking & warning screens immediately after the welcome screen,
just before DMV selection and EULA.

--
Blocking the installation completely is considered slightly too
aggressive but we still want to dissuade users from doing so. Add an F9
hotkey on the critical issues screen which passes onto the next install
screen, this means users cannot simply through every screen to
ignore warnings.

I've preserved the structure of the warning(s) such that new ones can be easily added if necessary

Example of the check triggering:

[andyhhp]

First of all, per the subject, you'll break all AMD hardware.

As already said on the ticket, this is strictly a backwards step. It gains us nothing and it makes one aspect of getting the system installed harder.

Xapi produces precise errors for why VMs can't start, because I personally fixed that years ago. Xapi also checks for the other blocking factor to starting VMs which you are not checking for here.

[GeraldEV]

First of all, per the subject, you'll break all AMD hardware.

VT refers just to virtualisation support in this case, it checks for hvm-3.0-x86_32 in the /sys/hypervisor/properties/capabilities file which is present as expected on both Intel and AMD systems I've checked
So this is expected to behave correctly on both Intel and AMD hardware

Ross cannot view GitHub at the moment but has requested an option to skip this check for testing scenarios (via a command line option), which will be the next commit

As already said on the ticket, this is strictly a backwards step. It gains us nothing and it makes one aspect of getting the system installed harder.

Xapi produces precise errors for why VMs can't start, because I personally fixed that years ago. Xapi also checks for the other blocking factor to starting VMs which you are not checking for here.

Is this the error message you're referring to? (for this case):
"You attempted to run a VM on a host which doesn't have I/O virtualization (IOMMU/VT-d) enabled, which is needed by the VM."

I personally think catching the issue earlier (at install time) is more useful, whether or not we should block installations is up for discussion
Thoughts? @alexbrett @MarkSymsCtx @rosslagerwall

[freddy77]

There are 2 reasons why I'd nack this change:

• in XenRT there are tests testing the installer using Xen on Xen, this will break all these tests;
• from user prospective allowing to install Xen in anyive allowing to inst case allow to do the setting later instead of having to stop the installation, change the setting and start all again. Especially on a server where the process can take 5/10 minutes.

[alexbrett]

Would a compromise here be to make it something you have to explicitly acknowledge, e.g. press a function key or similar, not something you can trivially just "enter, enter, enter" through?

[GeraldEV]

I've added an F9 hotkey which will step past the Reboot button

[freddy77]

This is kind of a regression. It looks fine to me, I don't know if some usage could be affected. If some customer or XenRT rely on continue on these issues they will be surprised to say the least.
Not sure if this should also documented in some customer facing documentation (not referring to doc/parameters.txt or this repository anyway).

[GeraldEV]

Since the answerfile (unattended) installation isn't affected by these changes, it will only be an issue for manual interactive installations. But for those installations we now have a command line option and a function key to skip/ignore the blocking issues
A customer is not strictly blocked on installation but has to explicitly acknowledge the limitation (via the Fn key)

[freddy77]

Is there a way to specify this in the answerfile ?

[GeraldEV]

The blocker check has only been added to the TUI install, the answerfile install already ignores the warning (and now blocking) issues so an answerfile option is not necessary

[freddy77]

I don't know about snackutil but in many desktop environments for cancelling a dialog you have some system hot key (like ESC or Alt-F4 or Ctrl-Q) that could skip this F9. I think the check should be more strict about the F9, like the lambda setting a variable to make it possible to check this.
What should we do about the possible default cancel? Reopen the dialog?

[GeraldEV]

From testing:
ESC has no effect
Ctrl-Q has no effect
Alt-F4 closes the entire installer - displays a slightly odd message as if we're in an installed environment, the user can restart the installer with /opt/xensource/installer/init if they want and it will restart from scratch
There doesn't appear to be any way of closing or skipping the individual dialog box beyond the ways we've added
To be safe I'll add your suggestion and use a REPEAT if no button was selected :D