Windows VMs stuck on boot after Proxmox Upgrade to 7.0
- Thread starter lolomat
- Start date
I've read some posts about Windows issues and sata-disks, might that be the problem here as well?
We have like six different clusters already running on 7.1 and I face similar issue, most of the when have the ha active for the vm. We no longer use sata-disk as HDD/SSD, we use SCSI with a virtio-scsi single controller, and face similar issue. That doesn't mean we don't use SATA at all, we keep using it for the CD/DVD instead of IDE. Also we face the issue on other Operative Systems, not just windows. We face the issue as well on Linux deb-based and on FreeBSD based, therefore three complete different OS type kernels face similar issue.
Interesting, I've not seen any issues at all..
How do you guys run backups? Might it be that communication with Qemu on fsfreeze-commands and such cause the 'controllers' of the VM to get confused?
How do you guys run backups? Might it be that communication with Qemu on fsfreeze-commands and such cause the 'controllers' of the VM to get confused?
we have same problems, we also use Proxmox Backup Server
I've testet a fresh Windows VM, Reboot no problem, made Backup with PBS, Reboot no Problem, let the VM run for a few days, VM stuck on reboot.
Seems to be a problem when the VM is running some days, bot seems not te be an issue caused by Backup...
I've testet a fresh Windows VM, Reboot no problem, made Backup with PBS, Reboot no Problem, let the VM run for a few days, VM stuck on reboot.
Seems to be a problem when the VM is running some days, bot seems not te be an issue caused by Backup...
We also got the problem here - yesterday morning all windows VM were stuck on rebooting (because an automatic windows update triggered a reboot at night), no problems on the linux VMs.
I just had the exact same problem on our cloud infrastructure after rebooting a windows VM where an updating was pending.
Both cluster have two nodes (one with ZFS and replication, one with NFS shared storage) and all the latest versions as of now, there where no reboots pending, both clusters have totally differenty hardwares (one cluster locally with 2x dell R7525, one cluster at hetzner online with dedicated AX101)
The problem did not appear on manual windows restart from inside the vm. qemu-guest-agent is installed everywhere. we are using PBS for backups.
I just had the exact same problem on our cloud infrastructure after rebooting a windows VM where an updating was pending.
Both cluster have two nodes (one with ZFS and replication, one with NFS shared storage) and all the latest versions as of now, there where no reboots pending, both clusters have totally differenty hardwares (one cluster locally with 2x dell R7525, one cluster at hetzner online with dedicated AX101)
The problem did not appear on manual windows restart from inside the vm. qemu-guest-agent is installed everywhere. we are using PBS for backups.
Code:
proxmox-ve: 7.1-1 (running kernel: 5.13.19-1-pve)
pve-manager: 7.1-10 (running version: 7.1-10/6ddebafe)
pve-kernel-helper: 7.1-8
pve-kernel-5.13: 7.1-6
pve-kernel-5.11: 7.0-10
pve-kernel-5.13.19-3-pve: 5.13.19-7
pve-kernel-5.13.19-2-pve: 5.13.19-4
pve-kernel-5.13.19-1-pve: 5.13.19-3
pve-kernel-5.11.22-7-pve: 5.11.22-12
pve-kernel-5.11.22-4-pve: 5.11.22-9
ceph-fuse: 15.2.14-pve1
corosync: 3.1.5-pve2
criu: 3.15-1+pve-1
glusterfs-client: 9.2-1
ifupdown2: 3.1.0-1+pmx3
ksm-control-daemon: 1.4-1
libjs-extjs: 7.0.0-1
libknet1: 1.22-pve2
libproxmox-acme-perl: 1.4.1
libproxmox-backup-qemu0: 1.2.0-1
libpve-access-control: 7.1-6
libpve-apiclient-perl: 3.2-1
libpve-common-perl: 7.1-2
libpve-guest-common-perl: 4.0-3
libpve-http-server-perl: 4.1-1
libpve-network-perl: 0.6.2
libpve-storage-perl: 7.0-15
libspice-server1: 0.14.3-2.1
lvm2: 2.03.11-2.1
lxc-pve: 4.0.11-1
lxcfs: 4.0.11-pve1
novnc-pve: 1.3.0-1
proxmox-backup-client: 2.1.4-1
proxmox-backup-file-restore: 2.1.4-1
proxmox-mini-journalreader: 1.3-1
proxmox-widget-toolkit: 3.4-5
pve-cluster: 7.1-3
pve-container: 4.1-3
pve-docs: 7.1-2
pve-edk2-firmware: 3.20210831-2
pve-firewall: 4.2-5
pve-firmware: 3.3-4
pve-ha-manager: 3.3-3
pve-i18n: 2.6-2
pve-qemu-kvm: 6.1.0-3
pve-xtermjs: 4.16.0-1
qemu-server: 7.1-4
smartmontools: 7.2-1
spiceterm: 3.2-2
swtpm: 0.7.0~rc1+2
vncterm: 1.7-1
zfsutils-linux: 2.1.2-pve1
We are also faced with this problem. In order to be able to maybe establish a connection to the Qemu Guest Agent or driver versions, which version of the VirtIO Drivers ISO did you use on your Windows VMs? Please also post the chipset used (Proxmox VE GUI > VM > Hardware > Machine [e.g. pc-i440fx-5.1]).
Thank you very much.
Last edited:
We had the issue with a windows server 2022 VM and virtio tools 0.1.208, vm config:
Code:
agent: 1
balloon: 0
bios: ovmf
boot: order=scsi0
cores: 4
hotplug: disk,network,usb
machine: pc-q35-6.0
memory: 4096
name: xxxx1
net0: virtio=9E:5A:60:XX:XX:XX,bridge=vmbr0,firewall=1
net1: virtio=EA:F0:EA:XX:XX:XX,bridge=vnet1,firewall=1,tag=10
numa: 0
onboot: 1
ostype: win10
scsi0: zfs:vm-105-disk-0,discard=on,size=128G
scsihw: virtio-scsi-pci
smbios1: uuid=f46cc7d8-9539-400a-ae78-0e71f23bbe7e
sockets: 1
vmgenid: 4304982c-34d1-4e51-ae61-b7353db96cc9and also on a different cluster as stated before with multiple windows server 2019 VMs with virtio/qemu-guest 0.1.196, config:
Code:
agent: 1,fstrim_cloned_disks=1
balloon: 0
bios: ovmf
boot: order=scsi0
cores: 4
efidisk0: nas-ssd:100/vm-100-disk-1.qcow2,size=128K
hotplug: disk,network,usb,memory,cpu
memory: 8192
name: xxxx2
net0: virtio=06:8A:9D:F5:XX:XX,bridge=vmbr0,tag=10
numa: 1
onboot: 1
ostype: win10
protection: 1
scsi0: nas-ssd:100/vm-100-disk-0.qcow2,discard=on,size=128G,ssd=1
scsihw: virtio-scsi-pci
smbios1: uuid=646f7631-4eb8-47d2-9a76-87252c23f85c
sockets: 1
startup: order=1,up=60
tablet: 1
vmgenid: 7e5e6855-f551-423e-a023-8c34f364a85aWe have been experiencing this too. It's seems completely random. Some windows VMs will do it pretty consistently, some are random like every 2 weeks we have to stop/start then it's fine. Some never have the issue. Most of the ones that seem to have the issue were imported (qm import) from hyper-v.
Also to add. We are running one cluster with VE 6.4-13 - that cluster is not showing this issue at all with windows, Linux, native and imported VMs.
The cluster that is showing this issue is running VE 7.1-4.
The cluster that is showing this issue is running VE 7.1-4.
We have tested a few things. This seems to be an issue with Hyper-V VMs imported to ProxMox on 7.1-4. We have been importing Gen 2 Hyper-V VMs into ProxMox and also importing from another KVM based hyper-visor using qm importdisk. The KVM based hyper-visor imports work fine, the Hyper-v imports have been causing trouble ONLY on 7.1-4. The Hyper-v imports to 6.4-13 are not having this issue.
I am worried that now upgrading our cluster to 7.1-4 is going to make this issue appear. Windows VMs get stuck on a black screen and the only solution is to stop/start. This is not ideal as it means we are having to fix this primitively at the wee hours of the morning before the scheduled reboots take effect.
I think this is an issue with UEFI / EFI but I am not 100% at this point, but 7.1-4 seems to be the only thing that is different and showing these issues.
I am worried that now upgrading our cluster to 7.1-4 is going to make this issue appear. Windows VMs get stuck on a black screen and the only solution is to stop/start. This is not ideal as it means we are having to fix this primitively at the wee hours of the morning before the scheduled reboots take effect.
I think this is an issue with UEFI / EFI but I am not 100% at this point, but 7.1-4 seems to be the only thing that is different and showing these issues.
Last edited:
Hello
by us the problem exists on windows vm's importet from esxi 6.5. and
a fresh installed windows server 2019 on pve 6.x after upgrade to pve 7.1
kr
Roland
by us the problem exists on windows vm's importet from esxi 6.5. and
a fresh installed windows server 2019 on pve 6.x after upgrade to pve 7.1
kr
Roland
Last edited: