Search results

And yes, exactly the same here, some have uptime upwards of 3 months! However I think the common factor here is that only AMD Ryzen 7000 series appears to be affected. I was having crashes even with the CPU set to max. I assume it must be a problem with nested virtualization then.

Glad to hear it's not just me! I had initially (wrongly?) suspected that Windows VMs were at fault, but we have other hypervisors on the same hardware which seem to be just fine, only two are affected. I deployed a spare one recently, and it also starts to reboot randomly after I live migrate...

We have been having this problem on 2 hypervisors running 7950X3D and 7950X CPUs, we run about 50+ in total, 8 of which are 7950X3D's, and one is a 7950X. I am confident this is not a hardware problem, ran memtests, and after migrating all VMs to another server, this kept reoccurring. We use...

Disabling/enabling discard didn't seem to help much. It has gotten a lot less frequent recently though, not sure what has changed.

This might actually be unrelated, the timestamp in the VM is 20:03 EST, this server had a running backup and the backup had failed due to a hardware problem with the backup server at around the same time. This behaviour isn't really ideal :p (no iothread, VirtIO SCSI controller) INFO: 69%...

It happened on another VM, not sure if related. The output of this command above was 107. I grabbed kernel logs from the guest:

Thanks for your reply. It's not lack of space, there's enough space available on all these servers.

I'm not seeing anything interesting in the host, I should have grabbed logs from the guest but in an attempt to minimize downtime I didn't think of that. However, I did briefly go through the error messages on the VM console, and they were along the lines of sd hung task I believe. Perhaps this...

This is actually not from the large single VMs where the issue was rampant, this is from another hypervisor where I didn't notice issues before. iothread isn't enabled as well, and controller is VirtIO SCSI.

That's great, hopefully it is merged and rolled out ASAP.

Just noticed another stuck VM: { "QMP": { "version": { "qemu": { "micro": 2, "minor": 1, "major": 8 }, "package": "pve-qemu-kvm_8.1.2-6" }, "capabilities": [] } } { "return": {} } { "return": [ { "io-status": "ok"...

Interesting, thank you, I know this problem occurs on other applications when things get busy as the defaults are low, never really even thought that this would have been a problem on Proxmox. Maybe Proxmox should ship with higher defaults in future, such as 1048576?

I believe it is, it's a single VM on this host.

Thanks for your reply, here's the output from the PVE host: 41368 / 1024 kvm (PID 3721702) 2496 / 1024 pmxcfs (PID 1221) 660 / 1024 rrdcached (PID 1211) 216 / 1024 tuned (PID 1156) 148 / 1024...

From one such server: df -i / Filesystem Inodes IUsed IFree IUse% Mounted on /dev/sda1 671023104 86758 670936346 1% /

All are using ext4

Thank you very much for your reply. Unfortunately in most cases the guest console got spammed with systemd messages stating the disk was readonly. I was able to grab the error right after in one or two instances, I don't have a screenshot but it was something like this: validate_block_bitmap...

I have been observing VM disks going readonly randomly (every 5-7 days, it's not a regular pattern). This appears to only be happening to VMs with very large disks, such as 4TB or more. I have a fairly large deployment with over 50 hypervisors. The VMs have a local RAID 1/RAID 10 disk, I have...

My storage is regular raw files on a EXT4 partition. I'm primarily curious if disk writes are hijacked to write to both the backup and the actual disk, as limited bandwidth seems to aggravate this.

When trying to backup a large VM to a remote server using vzdump (snapshot mode), the writes on the VM appear to be slowed down greatly. Are disk writes affected (maybe writes are slowed down during a backup) when a backup is in progress, to maintain consistency?