Windows 7 VM installation hangs


Recommended Posts

Hi,

I'm trying to install Win 7 to a VM with the following settings:

  • 1440fx-3
  • CPUs pinned: 2,6,3,7
  • OVMF
  • raw disk
  • GPU = VNC / QXL

After adjusting the UEFI to boot from the ISO, I can connect to the VM using VNC. I see the message "press any key to boot from CD", I hit a key, a loading bar completes, then finally the Starting Windows screen shows, then ... nothing.

 

Unraid shows various CPUs scaling up and down until around the time the VNC screen goes black. At that point, one CPU core stays pegged at 100% for 20m and going. Unraid terminal shows qemu-system-x86 at 100%. Ram usage is at 50% and the server is otherwise idle.

 

Any ideas / suggestions?

Link to comment
  • 1 month later...

I was able to install the VM but I can't add more vCPU cores or it crashes on startup. It offers to run startup repair (then hangs with a black screen) or boot normally, which crashes and restarts. That's with the video driver set to QXL or Cirrus.

 

So we have a Windows 7 VM that works on half a core or won't boot with multiple cores. Any tricks I'm missing? I'd rather not reinstall but I'm open to that if it works.

Link to comment
  • 6 months later...
  • 4 months later...
On 10/2/2019 at 9:39 PM, KptnKMan said:

I'm having the same issue, when trying to setup a Windows 7 VM.

 

Got everything running, but cannot add more cores, as it hangs immediately and will not boot.

 

Has anyone managed to understand what is happening?

Same issue here... any ideas, there was another post about changing the CPU mode to emulated?

Link to comment
  • 4 months later...

I did not tested to extend the amount of cores so far, but I had no problem to install W7 Ultimate with 2 Cores after I changed the Machine to Q35-4.2 and the BIOS to SeaBIOS. The main reason was SeaBIOS. With OVMF it rebooted or freezed while showing the Windows Logo constantly (even with a single core setup). When the installation has been finished, I will try to extend the cores and try a second installation with i440fx and 4 Cores. Feedback follows...

Edited by mgutt
Link to comment

After testing several VM settings and wondering why SeaBIOS works and OVMF not, I found out that I missed to create an UEFI compatible W7 ISO. 🙈

 

But funny is, that sometimes I was able to install the non-UEFI version (with the UEFI-only OVMF Bios) after I created the VM multiple times and started them parallel. It seems it never boots with the first port (VNC:5900), but following started images (VNC:5901, VNC:5902, etc) have a chance to work (even with multiple cores selected). But most of the time it freezed while booting the setup (showing a black screen) or rebooted after the "windows is loading files" progress bar.

Edited by mgutt
Link to comment

Although I build an UEFI ISO, I'm still not successful on running the setup on every created VM. And now I stumbled upon this:

https://support.microsoft.com/en-us/help/2828074/windows-7-setup-hangs-at-starting-windows-on-surface-pro

"

Symptoms

If you attempt to install 64-bit version of Windows 7 on a Surface Pro or other UEFI-based computer, the Setup may hang at "Starting Windows" screen and the Setup process may not complete.

Cause

The computer does not support legacy BIOS interrupt 10 (INT 10H)."

 

And this manual of OVMF:

https://access.redhat.com/node/1434903/40/0

“15.9.2   Secondary Video Service: Int10h (VBE) Shim
When QemuVideoDxe binds the first Standard VGA or QXL VGA device, and there is no real 
VGA BIOS present in the C to F segments (which could originate from a legacy PCI option 
ROM -- refer to Compatibility Support Module (CSM), then QemuVideoDxe installs a minimal, 
"fake" VGA BIOS -- an Int10h (VBE) "shim".
The shim is implemented in 16-bit assembly in "OvmfPkg/QemuVideoDxe/VbeShim.asm". 
The "VbeShim.sh" shell script assembles it and formats it as a C array ("VbeShim.h") with the
help of the "nasm" utility. The driver's InstallVbeShim() function copies the shim in place (the 
C segment), and fills in the VBE Info and VBE Mode Info structures. The real-mode 10h 
interrupt vector is pointed to the shim's handler. 
The shim is (correctly) irrelevant and invisible for all UEFI operating systems we know about 
-- except Windows Server 2008 R2 and other Windows operating systems in that family.
Namely, the Windows 2008 R2 SP1 (and Windows 7) UEFI guest's default video driver 
dereferences the real mode Int10h vector, loads the pointed-to handler code, and executes 
what it thinks to be VGA BIOS services in an internal real-mode emulator. Consequently, 
video mode switching used not to work in Windows 2008 R2 SP1 when it ran on the "pure 
UEFI" build of OVMF, making the guest uninstallable. Hence the (otherwise optional, non-
default) Compatibility Support Module (CSM) ended up a requirement for running such 
guests.
The hard dependency on the sophisticated SeaBIOS CSM and the complex supporting edk2 
infrastructure, for enabling this family of guests, was considered sub-optimal by some 
members of the upstream community, 
♦ and was certainly considered a serious maintenance disadvantage for Red Hat Enterprise 
Linux 7.1 hosts.
Thus, the shim has been collaboratively developed for the Windows 7 / Windows Server 2008
R2 family. The shim provides a real stdvga / QXL implementation for the few services that are 
in fact necessary for the Windows 2008 R2 SP1 (and Windows 7) UEFI guest, plus some 
"fakes" that the guest invokes but whose effect is not important. The only supported mode is 
1024x768x32, which is enough to install the guest and then upgrade its video driver to the 
full-featured QXL XDDM one.

 

The C segment is not present in the UEFI memory map prepared by OVMF. Memory space 
that would cover it is not added (either in PEI, in the form of memory resource descriptor 
HOBs, or in DXE, via gDS->AddMemorySpace()). This way the handler body is invisible to all 
other UEFI guests, and the rest of edk2.
The Int10h real-mode IVT entry is covered with a Boot Services Code page, making that too 
inaccessible to the rest of edk2. Due to the allocation type, UEFI guest OSes different from 
the Windows Server 2008 family can reclaim the page at zero. (The Windows 2008 family 
accesses that page regardless of the allocation type.)“

 

If I understand it correct, the default OVMF installation does not support INT10H in a way Windows 7 needs it. But as I said I still was successful installing Windows 7 UEFI randomly. I will create a little video for that.

Link to comment
  • 3 months later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.