Search results

Also ensure the spinners are CMR and not SMR (shingled). Those will give you serious performance hits, especially when running with non-synthetic reads and writes.

I've never had that be an issue with my Windows VMs. Backed up, restored, migrated. If you changed machine type and CPU type, and/or more virtual hardware parameters though you may be risking a re-activation. That should still be resolvable with a manual activation as well.

As an update: Updated to the 5.15.39-1 kernel this morning and disabled the hookscript. Upon reboot the VM started without issue, and I verified passthrough was behaving as expected. So it looks like at some point a kernel update resolved the issue causing the framebuffer to improperly reserve...

This is a now known issue, been kicking around for a little bit: https://forum.proxmox.com/threads/windows-vms-stuck-on-boot-after-proxmox-upgrade-to-7-0.100744/

No BOOTFB in /proc/iomem. And I did run the update-initramfs -u and proxmox-boot-tool refresh. As stated, it worked fine before the 5.15 branch. I am still on 5.15.35-6, so maybe I need to update again and try removing the hookscript and see what happens.

I sure did not install any drivers on the Proxmox host. Only changes I've made to the install are the steps to enable pcie passthrough. I will verify again next time I can reboot the host, but for what its worth all of this was set up and working before the 5.15 kernel. I only had to start...

Ah, I did end up doing that. Went through my configs and found them as expected. However, with lscpi -nnk are we only concerned with the kernel driver in use, or also the kernel modules? Because as of now I do have the nouveau and nvidia drivers blacklsited and the kernel driver in use is vfio-pci.

I don't believe so. I just followed this guide: https://pve.proxmox.com/wiki/PCI(e)_Passthrough

Host OS GPU (console, post, etc.): ASPEED Graphics Controller (rev41) Passthrough GPU: NVIDIA GeForce GP106 (GTX1060 6GB)

I do have a boot GPU specified in BIOS, but this issue affected my system anyways. I have the hookscript setup working well for me, but I have been keeping an eye out for a more "persistent" change. Not sure I want to kill my access to boot logging though.

And there's no way to disable per GPU?

Are there any downsides to disabling the simple framebuffer?

For you and anyone else running into this, I was able to get my home server working with Nvidia passthrough again on the new kernel using the script found in this thread and the other changes I mention: https://forum.proxmox.com/threads/gpu-passthrough-issues-after-upgrade-to-7-2.109051/post-471546

The behavior has seemingly stopped for me too. I personally suspect the Microsoft kernel had some atrocious behavior going on, but I would still love to see a patch on Proxmox. No matter how much Microsoft poisons their own kernels they can't make me go back to Hyper-V.

Adding, this worked for me, as well as ENABLING ROM Bar, setting CPU to KVM64, and disabling Ballooning memory. Previously I had ROM Bar disabled, CPU set to Host just to get the PCIe passthrough to work. Ballooning was working before, but does not seem to work with the 5.15 kernel and PCIe...

Node1 Dell R720xd 2x Intel Xeon E5-2650 v2 128GB RAM OS on 2x SHGS31-500GS-2 via ZFS RAID1 10x Seagate Nytro 1551 1.92TB for Ceph Node2 Supermicro H8DGU based 2x AMD Opteron 6348 64GB RAM OS on 2x WD1004FBYZ via ZFS RAID1 6x Seagate Nytro 1551 1.92TB for Ceph Node3 Dell R750 2x Intel Xeon...

No issues specific to 7.2 here. Upgraded our four server cluster with Ceph storage without a single problem or outage.

Just adding to the voices that I have observed this behavior as well. proxmox-ve: 7.1-1 (running kernel: 5.13.19-5-pve) pve-manager: 7.1-10 (running version: 7.1-10/6ddebafe) pve-kernel-helper: 7.1-12 pve-kernel-5.13: 7.1-8 pve-kernel-5.11: 7.0-10 pve-kernel-5.3: 6.1-6 pve-kernel-5.13.19-5-pve...

Verified network infrastructure issue. RSTP was indeed forcing corosync and other traffic along a route it had no business on. Adjusted RSTP values and have not had a node crash since.

My nodes are current. Further investigation suggests potential network infrastructure issue. Will post results. EDIT: Bad RSTP priority was bad, lowest performant switch in the stack became root. Switch stats show peaks of usage through the uplink and downlink ports soon before fencing events...