Windows 24H2 Update Taking Forever

[cshill]

As the title states I'm trying to understand what is occurring in the system for why the feature update is taking such a significant time to update during the reboot cycle. I noticed when it goes into the first cycle it loads relatively quickly, maybe a 6 minute cycle from 0-100% then it reboots. This 2nd portion is where the update severely lags the system from 6 minutes up to 30 minutes. I can't really blame the feature update as it loads about the same amount of time as 6-7 minutes across hardware. What I'm asking is what is occurring during this reboot that Proxmox has a challenge correcting?

 

[cheiss]

Hi,

you do not specify anything about your system or the VMs configuration.
Can you please provide some information about your hosts and the output of pveversion -v and qm config <vmid>?

Have you followed the Windows 10 guest best practices? Are you using the virtio drivers?

 

[Fantu]

@cshill I suggest to post also virtio drivers version to check if is one of the version with issue on the disks: https://forum.proxmox.com/threads/r...device-system-unresponsive.139160/post-725794
I had this issue on one windows 2019 before a downgrade of virtioscsi driver (recently I updated to 0.1.266 and result solved) and can be reproducible on high load, like windows update, so I suppose can be a possible cause.


@cheiss I suggest updating the wiki page mentioning the virtio versions of this issue that I think can be useful.

 

[cshill]

Hi,

you do not specify anything about your system or the VMs configuration.
Can you please provide some information about your hosts and the output of pveversion -v and qm config <vmid>?

Have you followed the Windows 10 guest best practices? Are you using the virtio drivers?

Hi,
I apologize, I will post the following below:

PVE Version

proxmox-ve: 8.3.0 (running kernel: 6.8.12-4-pve)
pve-manager: 8.3.0 (running version: 8.3.0/c1689ccb1065a83b)
proxmox-kernel-helper: 8.1.0
proxmox-kernel-6.8: 6.8.12-4
proxmox-kernel-6.8.12-4-pve-signed: 6.8.12-4
proxmox-kernel-6.8.12-3-pve-signed: 6.8.12-3
proxmox-kernel-6.8.4-2-pve-signed: 6.8.4-2
ceph-fuse: 18.2.4-pve3
corosync: 3.1.7-pve3
criu: 3.17.1-2
glusterfs-client: 10.3-5
ifupdown2: 3.2.0-1+pmx11
ksm-control-daemon: 1.5-1
libjs-extjs: 7.0.0-5
libknet1: 1.28-pve1
libproxmox-acme-perl: 1.5.1
libproxmox-backup-qemu0: 1.4.1
libproxmox-rs-perl: 0.3.4
libpve-access-control: 8.2.0
libpve-apiclient-perl: 3.3.2
libpve-cluster-api-perl: 8.0.10
libpve-cluster-perl: 8.0.10
libpve-common-perl: 8.2.9
libpve-guest-common-perl: 5.1.6
libpve-http-server-perl: 5.1.2
libpve-network-perl: 0.10.0
libpve-rs-perl: 0.9.0
libpve-storage-perl: 8.2.9
libspice-server1: 0.15.1-1
lvm2: 2.03.16-2
lxc-pve: 6.0.0-1
lxcfs: 6.0.0-pve2
novnc-pve: 1.5.0-1
proxmox-backup-client: 3.2.9-1
proxmox-backup-file-restore: 3.2.9-1
proxmox-firewall: 0.6.0
proxmox-kernel-helper: 8.1.0
proxmox-mail-forward: 0.3.1
proxmox-mini-journalreader: 1.4.0
proxmox-offline-mirror-helper: 0.6.7
proxmox-widget-toolkit: 4.3.1
pve-cluster: 8.0.10
pve-container: 5.2.2
pve-docs: 8.3.1
pve-edk2-firmware: 4.2023.08-4
pve-esxi-import-tools: 0.7.2
pve-firewall: 5.1.0
pve-firmware: 3.14-1
pve-ha-manager: 4.0.6
pve-i18n: 3.3.1
pve-qemu-kvm: 9.0.2-4
pve-xtermjs: 5.3.0-3
qemu-server: 8.3.0
smartmontools: 7.3-pve1
spiceterm: 3.3.0
swtpm: 0.8.0+pve1
vncterm: 1.8.0

VM Config

agent: 1
bios: ovmf
boot: order=scsi0;ide0;ide2;net0
cores: 4
cpu: host
efidisk0: Datastore4:107/vm-107-disk-0.qcow2,efitype=4m,pre-enrolled-keys=1,size=528K
ide0: local:iso/virtio-win-0.1.262.iso,media=cdrom,size=708140K
ide2: local:iso/Windows 11.iso,media=cdrom,size=5529856K
machine: pc-i440fx-9.0,viommu=virtio
memory: 8192
meta: creation-qemu=9.0.2,ctime=1731710709
name: Test11
net0: virtio=BC:24:11:85:97:6B,bridge=vmbr1,firewall=1
numa: 0
ostype: win11
scsi0: Datastore4:107/vm-107-disk-1.qcow2,iothread=1,size=75G
scsi1: Datastore2:107/vm-107-disk-0.qcow2,backup=0,iothread=1,size=256G
scsihw: virtio-scsi-single
smbios1: uuid=3a8f146d-74ef-4be5-8e46-a3e86ee0aa16
sockets: 1
tpmstate0: Datastore4:107/vm-107-disk-2.raw,size=4M,version=v2.0
vmgenid: f5257a0c-f8af-4da3-8077-ee24dc92ca67

I have the Virtio Driverd1.266 installed with guest tools. I had some complaints from testers that the windows machine felt slow on 1.262 so I tested with 1.266 and it seemed fine to me but the feature update is the problem. Disk access speeds and general processing seem just fine to me again but then I noticed the feature update was having a problem. Most physical systems are capable of handling the 24H2 feature update with about 6-7 minutes during the reboot phase. The virtual machine takes about 25-30 minutes. I did not have a clock speed on it but roughly noticed it started at 1:37 PM and I think finished at 2:00 PM, maybe a bit after? My colleague did his own test, same specs and datastores, and corroborated the time it took at about 25 minutes.
In the VM Config Datastore 4 is the Operating system running on a sata SSD with the backup hard drive on Datastore 2, HDD.

This is all running on a PowerEdge 540 server. At the time no other VMs were active utilizing the disk speed, the VM was isolated and allowed to use all of the disk speed. Granted I could have provided more cores or memory for the test but most VMs will be utilizing similar specs so that's what I went with.

 

[cshill]

Hi Everyone,
I was wondering if anyone was able to take a look at this? New VMs will be generated utilizing a new Windows 11 ISO but I do have some VMs I would like to upgrade and was wondering if anyone had an idea why this takes so long.