Search results

The "whatever reason" is hidden in this statement: ..the vmbr0 interfaces on the other cluster members... The Ethernet case is normally bridged. Everything is basically connected to a managed switch, in your case vmbr0. There is no IP routing going on, the kernel does not care about the IP...

Does your system have a separate /boot partition? Maybe it is broken or out of space.

How is the host system supposed to work when it has no RAM available?

Only if you installed PVE on a different disk or partition and set up dual boot.

Yes, it is NAT at layer 2, basically. The problem is that the access point your PVE is connected to won't (usually...there are exceptions) accept Ethernet frames that did not come from the MAC address that is associated with it. So I don't see any way to do this without some kind of NAT...

There is a way to do it but it is complex and you need to do configuration for each VM that will be using the bridge. Because when you installed a Desktop Environment it brought in Network Manager to control the interfaces. If you want to do it manually with /etc/network/interfaces you should...

It isn't a matter of PVE "being able to boot the VM" as much it is a question of drivers. Does Windows have drivers for the hardware you have given it? A lot depends on the previous setup since Windows doesn't install all the drivers it has but only the ones it thinks it needs. Maybe try SATA...

Your rootfs (/dev/mapper/pve-root) is full. I'm going to go out on a limb and guess that your gdrive mount was at some point not present and backups got written to /mnt/gdrive/proxmox_backup. You can check by un-mounting it and checking what you find under /mnt/gdrive.

Yes. SPICE is one of the choices when you set up the video in a VM. There are other ways to do virtual desktops on Linux VM as well. I use NoMachine.

SPICE will give you audio, but you asked about RDP. RDP is not native to Linux. ETA: I don't know what videos you watched, but most virtualization workloads aren't virtual desktops. If you're running a web server or mail server or whatever you don't need sound.

You need to manually build and install the pulseaudio sound redirector: https://github.com/neutrinolabs/pulseaudio-module-xrdp

Presumably. That's what it does if you do a manual shutdown.

Maybe you should have only the PVE host do the shutdown and not also the guest.

To expand on what @LnxBil said, you probably have the Debian version still installed. You can verify with "dpkg -l curl". The problem is your library path. Curl is a command-line tool + a library. What is happening seems to be that the wrong library version is being found. Which means that...

Why is there a directory called /usr/lib/vmware in the first place? That's not a normal thing on PVE. Are you running PVE on top of VMware? ETA: In other words, it looks like you have installed some version of curl on your PVE that did not come from the PVE or Debian repositories.

Fatal glibc error: CPU does not support x86-64-v[ 0.959953] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00007f00 This seems to be saying the image was built to use some x86 instruction set extensions that aren't enabled. If you are using the default "kvm64" CPU settings that...

Yes, updating will get you to the current version. The issue with non-subscription repositories is that they might be slightly ahead in the package versions compared to the enterprise ones. This is normally not a problem and eventually the enterprise repositories will catch up. At that point...

The memory is shown in red. That generally means you have made a change that requires the VM to be stopped and restarted, but have not done so.

1 GB = 1000 * 1000 * 1000 = 1,000,000,000 bytes 1 GiB = 1024 * 1024 * 1024 = 1,073,741,824 bytes

I think it is pretty clear that the CVE is about the Image Builder and not PVE itself.