> As an industry, how to deal with this has been understood before the advent > This would seem to be more of an oversight than an inherent problem. 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. As an industry, how to deal with this has been understood before the advent of IBM's VM/360, in the 1960's.
This would seem to be more of an oversight than an inherent problem. 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. The problem is encountered when a guest operating system attempts to use affected facilities such as XSAVE.
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 solution is to disable Hyper-V, per the instructions in the Microsoft article. When OpenVMS attempts to bootstrap, the bootstrap will detect the problem and abort with an error message. Oracle VirtualBox does not give a warning. 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 įor those running OpenVMS x86-64 the cautionary note is that the CPU Check Python script cannot see that Hyper-V is present.
ORACLE VIRTUALBOX 64 BIT NOT AVAILABLE WINDOWS
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.
0 kommentar(er)
