A cautionary note for those of us who use Oracle Virtual Box and other Virtual Machines on our Windows systems to run OpenVMS x86-64. Microsoft's Hyper-V, an issue recognized by Microsoft in "Virtualization applications don't work together with Hyper-V, Device Guard, and Credential Guard" available at https://docs.microsoft.com/en-us/troubleshoot/windows-client/application-management/virtualization-apps-not-work-with-hyper-v

For those running OpenVMS x86-64 the cautionary note is that the CPU Check Python script cannot see that Hyper-V is present. Oracle VirtualBox does not give a warning. When OpenVMS attempts to bootstrap, the bootstrap will detect the problem and abort with an error message.

The solution is to disable Hyper-V, per the instructions in the Microsoft article. One may not be aware that Hyper-V is active, as there are reportedly certain situations where Hyper-V may be installed without clear warning of its presence.

The problem is encountered when a guest operating system attempts to use affected facilities such as XSAVE. There is often no indicator that there is an issue until a guest operating system, e.g., OpenVMS x86-64 attempts to use the conflicted feature.

This would seem to be more of an oversight than an inherent problem. As an industry, how to deal with this has been understood before the advent of IBM's VM/360, in the 1960's. When I started system programming OS/360 and HASP in the mid-1970s, sharing hardware feature between physical devices and simulated devices was well understood, the example being the HASP print, punch, and read pseudo devices.

- Bob Gezelter, http://www.rlgsc.com

On Monday, October 25, 2021 at 4:02:02 AM UTC-7, geze...@rlgsc.com wrote:
> A cautionary note for those of us who use Oracle Virtual Box and other Virtual Machines on our Windows systems to run OpenVMS x86-64. Microsoft's Hyper-V, an issue recognized by Microsoft in "Virtualization applications don't work together with Hyper-V, Device Guard, and Credential Guard" available at https://docs.microsoft.com/en-us/troubleshoot/windows-client/application-management/virtualization-apps-not-work-with-hyper-v

First I thought you meant running Virtual Box or VMware under Hyper-V, but it seems that you meant (or the link means) running it next to Hyper-V.

But why not run either directly (that is more obvious) or the virtualization system, under Hyper-V (it doesn't say about that one).

Hyper-V does sound interesting!

On Monday, October 25, 2021 at 4:02:02 AM UTC-7, geze...@rlgsc.com wrote:

(snip)

> This would seem to be more of an oversight than an inherent problem.
> As an industry, how to deal with this has been understood before the advent
> of IBM's VM/360, in the 1960's. When I started system programming OS/360
> and HASP in the mid-1970s, sharing hardware feature between physical
> devices and simulated devices was well understood, the example being
> the HASP print, punch, and read pseudo devices.

At least for VM/370 (and its predecessor CP/67, and successors), I always
thought IBM was lucky. One important feature of virtualization is that it
should not be possible, other than official ways (such as checking the
serial number), that one is virtualized.

It seems that the Motorola 68020 lets user programs read the bit that
indicates supervisor mode.

The only problem that VM/370 has, is that it can't emulate STCK, such that
the virtual machine has a different TOD clock. That mostly was a problem
testing Y2K fixes. I am not sure if that was changed later, or not.

Then S/370 added SIE, to speed up virtualization. From the beginning,
though, VM/370 was designed to be able to nest, such that one can test
new versions running under itself. (Though it might get slower.)

Otherwise, Hyper-V and Virtual Box should be designed to run under,
or over, each other, though possibly slower if the speed-ups can't
be used.

On 25/10/2021 13:02, Bob Gezelter wrote:> A cautionary note for those of us who use Oracle Virtual Box and
> other Virtual Machines on our Windows systems to run OpenVMS x86-64.
> Microsoft's Hyper-V, an issue recognized by Microsoft in
> "Virtualization applications don't work together with Hyper-V, Device
> Guard, and Credential Guard" available at
> https://docs.microsoft.com/en-us/troubleshoot/windows-client/application-management/virtualization-apps-not-work-with-hyper-v
>
> For those running OpenVMS x86-64 the cautionary note is that the CPU
> Check Python script cannot see that Hyper-V is present. Oracle
> VirtualBox does not give a warning. When OpenVMS attempts to
> bootstrap, the bootstrap will detect the problem and abort with an
> error message.
>
> The solution is to disable Hyper-V, per the instructions in the
> Microsoft article. One may not be aware that Hyper-V is active, as
> there are reportedly certain situations where Hyper-V may be
> installed without clear warning of its presence.
>
> The problem is encountered when a guest operating system attempts to
> use affected facilities such as XSAVE. There is often no indicator
> that there is an issue until a guest operating system, e.g., OpenVMS
> x86-64 attempts to use the conflicted feature.
>
> This would seem to be more of an oversight than an inherent problem.
> As an industry, how to deal with this has been understood before the
> advent of IBM's VM/360, in the 1960's. When I started system
> programming OS/360 and HASP in the mid-1970s, sharing hardware
> feature between physical devices and simulated devices was well
> understood, the example being the HASP print, punch, and read pseudo
> devices.
>
VirtualBox now works within the Hyper-V parent VM:

https://www.virtualbox.org/manual/UserManual.html#hyperv-support

I think I have actually tried that.

I use VirtualBox to run OS/2 since OS/2 will never run in Hyper-V directly.