One of my Proxmox hosts randomly loses network for 5-6 seconds at what appears to be random points throughout the day. I am usually using VMs via RDP, and they either pause or disconnect.
While investigating the issue I've noticed both pings to and from the host also stop, so it seems to be a...
I figured it was a long shot, but always worth documenting these data points.
If I see the same hostwide performance again, what's the best way to quantify what's going on? I didn't see anything unusual using top on the host for example.
I usually run a couple of desktops on a Proxmox host running on a Haswell Xeon with 32GB ram. Hardware capabilities aside, the setup has been running well for me. The host is part of a two box cluster (which I use for the datacentre UI and not resilience).
For the last three days or so my...
For anyone else who finds this, don't do what I did and replace everything vmbr0 with the above. You'll lose network access. Make sure you keep the bridge lines, so perhaps something like:
auto vmbr0
iface vmbr0 inet dhcp
bridge_ports eth0
bridge_stp off
bridge_fd 0...
It's worth noting that any kind of GPU passthrough will disable the proxmox SPICE setup.
I've gone the other way and set up "bespoke" remoting per VM. That's essentially RDP for Windows (although sometimes VNC for GPU/game streaming) and still tossing up between NoMachine and xRDP for Linux...
As we are now in the future, any sign of this functionality coming soon? ;)
I notice that the usage can be found in lvs say, so although I appreciate the guest-agent is the right way to do it, perhaps in the short term for LVM disks it can be picked up directly?
From https://github.com/prometheus-pve/prometheus-pve-exporter/issues/43, you can use tokens by using a slightly different config:
default:
user: "..."
token_name: "..."
token_value: "..."
@jfmanamtr this was great. Just out of interest, why do you create a token? It doesn't look like the pve exporter supports them? I had to use the user/pass.
If you already know how to build things then you'll have this fixed in less than 15 minutes.
If you don't then it's a fun (and safe enough) exercise to do that will take 2 hours or so.
This from the chap behind the IGD passthrough code in QEMU is very useful:
https://git.qemu.org/?p=qemu.git;a=blob;f=docs/igd-assign.txt;h=e17bb50789ada12b210897a5574bf89ee64b80fb;hb=HEAD
Just to report back that a deb-patched deb package has brought the functionality back via Proxmox server (subject to suppressing PCI bridge 2 as per https://forum.proxmox.com/threads/igd-passthrough-and-hard-coded-pci-bridges.68285)
Okay. Great - it being overridden is fine. In the meantime I figured out a patch that will work for all builds:
diff --git a/hw/vfio/pci-quirks.c b/hw/vfio/pci-quirks.c
index 2d348f8237..a633df965e 100644
--- a/hw/vfio/pci-quirks.c
+++ b/hw/vfio/pci-quirks.c
@@ -25,6 +25,7 @@
#include...
My fix is simply defining CONFIG_VFIO_IGD which I'm not sure will wash with them ;). I'm not familiar enough with their process to see how to introduce a preprocessor variable from a kconfig variable.
But since Proxmox always has CONFIG_PCI I might make it a deb patch. If I do, and install...
Instead of messing around with Proxmox patches I've reproduced the bug (and fix) in clean upstream sources. Filed a bug here:
https://bugs.launchpad.net/qemu/+bug/1882784
Thanks for the attention and help - I'm not sure if this should be marked solved as of now?
I'll be using a patched QEMU...
So I've verified that the normal build pulls in the refactored IGD code, and that it still doesn't work.
Reverting the patch however does.
I'll follow up with upstream, but in the meantime would the pve patches be doing something? I do doubt it but I thought I'd ask.
Ah, thanks for the insight, that package did the trick.
Regarding the QEMU5 commit I understood the same, that it should be there with CONFIG_PC_PCI, so reverting the patch will be part of my investigation.
I'm specifically looking for where for example CONFIG_PC_PCI might be defined. I'm...
Thanks for the reply. I've since made some progress but am now getting the following error trying to compile in a debian 10 container. I'll read the dev docs to see if there are any clues.
In file included from /root/pve-qemu/pve-qemu-kvm-5.0.0/include/qemu/timer.h:4,
from...
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.