Recent content by Andy Huang

"interesting" is one way to put it... money demanding is another :) Even after deleting some stuff, and running fstrim so the total is not encroaching on 16T limit, the hypervisor will still try to write beyond the 16T limit, resulting in errors, and then shooting the disk into read-only...

Hm... you may be on to something! # ls -lha total 17T drwxr----- 2 root root 4.0K Nov 20 2022 . drwxr-xr-x 11 root root 4.0K Mar 18 2022 .. -rw-r----- 1 root root 257G Nov 16 2022 vm-100-disk-2.qcow2.bak -rw-r----- 1 root root 48G May 27 05:50 vm-100-disk-1.qcow2 -rw-r----- 1 root root...

I'm facing similar, if not identical, problem here, except with newer versions. Figured I'd not necro the old thread, but if it is preferred by the moderation team, please merge as you deem fit. Here's my pveversion output: # pveversion -v proxmox-ve: 7.4-1 (running kernel: 5.15.107-2-pve)...

The plot thickens... I tried to attach it to a newly installed OpenMediaVault 4 VM, and it wouldn't start. I tried to run the command from shwocmd manually and I get this: kvm: -device vfio-pci,host=43:00.0,id=hostpci0.0,bus=pci.0,addr=0x10.0,x-vga=on,multifunction=on: vfio error: 0000:43:00.0...

Little bump on this... Anyone?

Forgot to include this: The PCI device is appearing under `Bus 1, device 0, function 0` and `Bus 1, device 0, function 1`.

I've followed the tutorial on the wiki and I'm still having nothing but Code 43. I've tried OVMF BIOS with PCI passthrough, as well as with PCIe passthrough, neither worked. I've also tried SeaBIOS with PCI passthrough, as well as with PCIe passthrough, neither worked. For each of the above...

Thanks for getting back! The KVM VMs are running as you've identified. The problem was the Web GUI manager not accessible. I wrote a loooong wall of text about how I dug deeper and found it may be SSL related, reverting to default settings, and testing from different machines... and when I got...

Sorry I typo'ed when I was making this post. I did dist-upgrade instead of upgrade. You physically cannot get an upgrade command to do a dist-upgrade change; and what was recorded in my .bash_history supports that.

I've recently upgraded from 5.3 to 5.4 using: sudo apt-get update sudo apt-get upgrade After rebooting, my PVE-manager isn't coming back online, though PVE daemon seems to be running. # service pvedaemon status ● pvedaemon.service - PVE API Daemon Loaded: loaded...

I wanted to do upgrade first to get to latest available in the same branch before I do dist-upgrade, but this definitely fixed the problem for me. Thanks!

I tried to run: apt-get upgrade It results in failure for these packages: Errors were encountered while processing: pve-firewall qemu-server pve-manager proxmox-ve pve-ha-manager pve-container When I try to run the debug command, I get this: $ journalctl -xn -- Logs begin at Tue 2015-12-08...

I'd also be interested; this is something that would be super ideal for offices. Employee come in, assign a PVE credential, git checkout code, vagrant up, and code happy on a VM provisioned on a central dev server.

I only have one physical server at this point. The database is in a separate VM from the web application, and can be moved to a separate physical if and when the need arise. I'm more debating as to how to virtualize and share resources properly, so the web application servers doesn't die and...

I have a web application that is about to see some traffic. Here are a few approaches I've thought of, but I don't know which one is best: Multiple VMs each with own files, with a Varnish front-end load balancing them Multiple VMs with a shared NFS on separate VM, with a Varnish front-end load...