Search results

Again, I advise to read the manual. You have what's called an LVM-thin setup. The installer set up the Logical Volume Manager, which is different from traditional partitions. It manages a chunk of disk space by carving it up into virtual block devices "on demand". When you make a VM a virtual...

That isn't what you want to do. You see that 1.7 TB "pve-data" thingy? That should show up in the gui as "local-lvm" or similar. That is where your VMs will go. Just set that as the storage when you create a VM. Then read the storage section of the manual.

I don't run a cluster but AFAIK the storages don't have to be the same size on all nodes for migration to work. You just need to have sufficient space on the target.

Why did you bring it up then? As far as I know the GUI only supports creating an LVM-thin on a whole disk. It isn't exactly an enterprise use-case to have other things on the same disk as your VM's, while it is one to have entire disks dedicated to VM storage. That being said, it can be done...

So do that and use Hyper-V as the hypervisor.

In that case you might be better served by a desktop virtualization solution: virt-manager, vmware, virtualbox. PVE is pitched as an enterprise solution and that comes with certain expectations of the users. Those other solutions claim to be easy for beginners. You are free to use it whatever...

One way is to "apt install bsd-mailx". Then your command becomes echo "whatever" | mail me@email.com... Or something like that.

Googling suggests that this is a feature Google wanted for Chromebooks. https://www.phoronix.com/news/AMDGPU-Secure-Display-Patches

The error I get is below. I run PVE 9 with kernel 6.14.11-3. : amdgpu 0000:c2:00.0: amdgpu: RAS: optional ras ta ucode is not available : amdgpu 0000:c2:00.0: amdgpu: RAP: optional rap ta ucode is not available : amdgpu 0000:c2:00.0: amdgpu: SECUREDISPLAY: securedisplay ta ucode is not...

I think pve-firmware package has the amdgpu firmware. Apparently you already have that? Maybe someone will know more if you tell us what GPU you have. I get an error about not having secure display microcode, but everything seems to work (and it is a different error from yours). My machine is a...

I got my FW desktop. PVE 9.0 runs fine on it. No issues so far. The GPU works with virtio-gl, which gives decent desktop performance for my usage. It replaces a Xeon D-1541 that was getting old. Relative to that it is very fast and has twice the core count with similar idle power. Passing the...

Also, the reason I asked how @powersupport how he was checking the time in the VM is because on Linux each user can have their own locale settings. The timedatectl settings only apply to root and as a default for other users. So it is entirely possible for different users to have different...

How are you reading "VM local time"? Do you log in to a shell, do you send a command to the agent, something else? About 99% of the time when there is a time discrepancy of an exact number of hours or half-hours and NTP is synchronized, it is a time zone problem. The uptime can obviously be...

By having them on the same subnet you are telling the kernel routing that it doesn't matter which one it uses because they are all the same. If they aren't actually the same, then you will see what you are seeing. Kernel picks one arbitrarily, because you told it that it doesn't matter.

If the interfaces are in different subnets, then the IP of the http server will tell the kernel which one to use. That's how routing works.

The official method for upgrading is here: https://pve.proxmox.com/wiki/Upgrade_from_8_to_9 Perhaps reviewing it will reveal a step that was overlooked. Did you see any error messages during the upgrade process?

DHCPOFFER of 192.168.48.100 from 192.168.48.1 DHCPREQUEST for 192.168.48.100 on eth1 to 255.255.255.255 port 67 DHCPOFFER of 192.168.48.200 from 192.168.48.1 DHCPREQUEST for 192.168.48.200 on eth0 to 255.255.255.255 port 67 DHCPACK of 192.168.48.100 from 192.168.48.1 These two ports are getting...

Again, from your log it appears that there are multiple interfaces on the same subnet. If they are not actually all connected somehow, this can't work as you want it to (and is a bad idea to begin with). You can still do what you want by only connecting one interface during installation. IOW, I...

To be clear, did you upgrade the Proxmox packages to PVE 9 or did you only upgrade the Debian packages? If the latter, you need to do the former as well.

Having a bunch of different interfaces on the same subnet with incomplete reachability between them is...sub-optimal. As you've noticed, since they are all on the same subnet the Linux kernel assumes they are equivalent and will just pick one to use for any given transaction. Maybe disconnect...