Windows 10 Pro x64 VM will freeze - Debian 11 "Bullseye" not
- Thread starter jmar83
- Start date
It freezes (on WebGUI and also on Remote Desktop)... while other 3 VMs (Debian 11) are stable since weeks... where shoud i start to debug - i have no idea...
Maybe to re-enable cache will solve that speed issue (currently, it will not freeze)... but write back cache seems to be buggy on proxmox 7.x version:
https://www.google.com/search?q=pro...AGDApIBAzIuMZgBAKABAcgBCMABAQ&sclient=gws-wiz
Because of that, now i willl use write throgh cache... maybe it will fasten it... ?
https://www.google.com/search?q=pro...AGDApIBAzIuMZgBAKABAcgBCMABAQ&sclient=gws-wiz
Because of that, now i willl use write throgh cache... maybe it will fasten it... ?
-> yesm seems so. But that's only a speed issue (i've changed many vm parameters to figure out the freezing problem), now with re-enabling write-throgh cache windows starts... (until it freezes the next time... ;-) )
Maybe i will better go back to M$ Hyper-V for Window$ VMs and using Proxmox only for Linux (or UNIX) VMs...?
But now i will try it with "latest" instead of "stable" VirtIO drivers... maybe that will solve my issue, but i don't think
But now i will try it with "latest" instead of "stable" VirtIO drivers... maybe that will solve my issue, but i don't think
Last edited:
Code:
root@proxmox:/# qm config 103
boot: order=scsi0;net0;sata0
cores: 2
memory: 8192
meta: creation-qemu=6.1.0,ctime=1637243392
name: windows10
net0: e1000=8A:2C:05:1D:04:44,bridge=vmbr0
numa: 0
ostype: l26
parent: after_config
sata0: local:iso/Windows.iso,media=cdrom,size=4416M
scsi0: raid5:103/vm-103-disk-0.qcow2,cache=writethrough,size=128G
scsihw: virtio-scsi-single
smbios1: uuid=0a65c5e6-7ae9-40c2-acb1-16ef19b9b9d8
sockets: 2
vmgenid: 33c26a58-eccd-4ac0-bef0-6f803ca143d3
Code:
root@proxmox:/# pveversion -v
proxmox-ve: 7.1-1 (running kernel: 5.14.0-0.bpo.2-amd64)
pve-manager: 7.1-7 (running version: 7.1-7/df5740ad)
pve-kernel-5.13: 7.1-4
pve-kernel-helper: 7.1-4
pve-kernel-5.11: 7.0-10
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.0
libproxmox-backup-qemu0: 1.2.0-1
libpve-access-control: 7.1-5
libpve-apiclient-perl: 3.2-1
libpve-common-perl: 7.0-14
libpve-guest-common-perl: 4.0-3
libpve-http-server-perl: 4.0-4
libpve-storage-perl: 7.0-15
libspice-server1: 0.14.3-2.1
lvm2: 2.03.11-2.1
lxc-pve: 4.0.9-4
lxcfs: 4.0.8-pve2
novnc-pve: 1.2.0-3
proxmox-backup-client: 2.1.2-1
proxmox-backup-file-restore: 2.1.2-1
proxmox-mini-journalreader: 1.3-1
proxmox-widget-toolkit: 3.4-4
pve-cluster: 7.1-2
pve-container: 4.1-2
pve-docs: 7.1-2
pve-edk2-firmware: 3.20210831-2
pve-firewall: 4.2-5
pve-firmware: 3.3-3
pve-ha-manager: 3.3-1
pve-i18n: 2.6-2
pve-qemu-kvm: 6.1.0-3
pve-xtermjs: 4.12.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.1-pve3-> I use the bullseye debian-backports kernel because proxmox 7.x will not work on HP ProLiant ML360 Gen9 -> https://forum.proxmox.com/threads/t...proliant-ml350-gen9-server.99449/#post-429284
With kernel 5.14.0-0.bpo.2-amd64, that issus does not occur anymore. Otherwise (with original Proxmox kernel), it will happen after 1 night of running in vm idle state - without any processes.
(So - there is no other way that to use 5.14.0-0.bpo.2-amd64 from bullseye debian-backports)
And, i use software RAID-5 on /mnt/raid5 path... but that should also work, can't be the reason for that behavior i.m.o. - otherwise, ther other 3 Linux VMs would also not work stable if the issue is a filesystem I/O problem on host OS...
And also the different kernel would not be reason - same thing: Otherweise, the Linux VMs also would have a problem
And also the different kernel would not be reason - same thing: Otherweise, the Linux VMs also would have a problem
Last edited:
"I use the bullseye debian-backports kernel because proxmox 7.x will not work on HP ProLiant ML360 Gen9"
Maybe a BIOS update would fix that, but we don't have access to all HP BIOS updates because the server is out of warranty...
Maybe a BIOS update would fix that, but we don't have access to all HP BIOS updates because the server is out of warranty...
No change with "latest" instead of "stable" VirtIO drivers: "Ballon" has the same driver date on stable and on latest:
DriverVer = 08/30/2021,100.85.104.20800
Maybe the problem is somewhere here, on "Advanced" options?
DriverVer = 08/30/2021,100.85.104.20800
Maybe the problem is somewhere here, on "Advanced" options?
Last edited:
Additional info: It doesnt seems to be a "complete" freeze, just an infinite lagging... the mouse cursor has this spinner animation and it never stops ince almost ~2 hours until i get that message:
Didn't help... now i set it back to defaault but with "I/O Thread" activated... will see what happens...
but i can't see any other way than to try all combinations and wait for ~2h until it occurs...
but i can't see any other way than to try all combinations and wait for ~2h until it occurs...
So it seems...
...is was that "Balloon" device.
After unchecking "Balloon" in VM RAM options, the VM is much more faster.
So far * - all is ok!!
* BUT: MAJOR QUESTION: Why Proxmox does not ask the user which OS he want to install? I mean it like [e.g.] VirtualBox... VirtualBox asks the user which OS he wants to install and creates a VM "hardware" configuration that fits to the chosen OS.
If Proxmox had that option, it would be possible that the balloon option is disabled after the user selected Window$ as a VM OS...
Just my humble opinion, but i can't see any reason to avoid that OS selection when createing a VM...!?
...is was that "Balloon" device.
After unchecking "Balloon" in VM RAM options, the VM is much more faster.
So far * - all is ok!!
* BUT: MAJOR QUESTION: Why Proxmox does not ask the user which OS he want to install? I mean it like [e.g.] VirtualBox... VirtualBox asks the user which OS he wants to install and creates a VM "hardware" configuration that fits to the chosen OS.
If Proxmox had that option, it would be possible that the balloon option is disabled after the user selected Window$ as a VM OS...
Just my humble opinion, but i can't see any reason to avoid that OS selection when createing a VM...!?