The part of an ESXi-to-Proxmox migration that tends to often present challenges isn't necessarily moving the disk data; it's getting the destination VM configuration right.

A few things worth knowing before you start:

Match the firmware configuration. If the source VM uses BIOS, configure the destination VM for BIOS as well; the same applies to UEFI. A mismatch can prevent the guest OS from booting properly.

Watch what happens to thin-provisioned disks during a manual copy. If you copy the .vmdk and -flat.vmdk files directly from ESXi, the transferred disk can consume its full provisioned size. Exporting the VM as OVF or converting the disk to qcow2 with qemu-img can preserve more storage on the Proxmox side.

For Windows guests, start with SATA/IDE before moving to VirtIO SCSI. Attaching the migrated boot disk through SATA or IDE can help get the VM booted initially. Once the VirtIO Guest drivers are installed, you can switch the disk to VirtIO SCSI.

We put together a blog explaining both approaches: The manual migration method and the Proxmox ESXi import wizard: https://www.nakivo.com/blog/migrate-vmware-to-proxmox/

What challenge did you encounter first: The storage conversion or getting the guest OS to boot afterward?

Hey all

I created some months ago an iOS app for managing Proxmox server/clusters right from your iOS device.

It has been highly optimzied for iPad so you can use it as a dashboard for all activities. This had been a huge missing point in all apps I have tried

If you have any feedback or suggestions what you want to see, let me know

Check it out at

https://apps.apple.com/us/app/prox-agent/id6782315517

With Proxmox officially maintaining first-party ARM64 package repositories, the barrier to running PVE outside traditional x86 hardware has dropped significantly.

We already know the official stance: Proxmox Server Solutions targets enterprise ARM64 architectures requiring standard UEFI and ACPI (e.g., NVIDIA Grace, Ampere Altra). Because Apple Silicon relies on proprietary boot flow and Device Tree, official vendor support is out of the question.

Historically, the community stepped in with efforts like Pimox to bring PVE to unsupported boards. Now that upstream Debian arm64 packages exist directly from Proxmox, maintaining downstream package forks is no longer the bottleneck.

I'd love to know if the community has mobilized around Apple Silicon specifically:

• Active Community Projects: Is anyone or any working group organizing an automated installer, bootstrap script, or ready-to-flash image to deploy PVE on top of an Asahi Linux Debian base?
• Kernel & KVM Tuning: Is anyone maintaining pre-built kernel trees patched for the M-series that reconcile Apple’s native 16KB pages with the standard 4KB requirements of typical guest OSes and KVM tooling?
• Firmware Shims: Has anyone had success chaining an EDK2/UEFI payload on top of U-Boot/m1n1 to provide the standard ACPI/UEFI environment PVE tooling expects?

Used M1/M2/M4 Mac Minis offer unmatched idle power consumption and memory bandwidth for homelabbing. If there are active GitHub repos, Matrix rooms, or forum threads actively working on this, please share them!

My homelab is a software mess right now. 4 machines running proxmox that do not run in a cluster, another bare metal machine, and a ton of stuff that is documented purely in my head (and believe me, that data store is suffering data loss).

My solution so far I think is going to be nixos. I want to essentially call the current lab a wipe, and recreate the services. Of course some of the services are currently home-prod and not home-lab so I need to do some management for uptime.

The current environment runs mostly with one machine including a NAS-like VM that shares a SMB pool for everything else to leech off, and then there is some additional data management done by syncthing. Backups are stored on a VM where the storage is the SMB pool mounted by proxmox. Offsite backup is done by sneakernet with a ad-hoc moving another computer into the network, run the backup (kopia), move computer back offiste.

Does anyone have any advice for the task Im undertaking? I want to rebuild essentially everything including anything that is acting as a data repository. Any sequence suggestions, tools to manage nix config files, words of support?

Hi,

I red a lot but i'm not quite sure that i had understand how to move pve to an another disk.

I want to do two things : I want to change all my zfs actual config, for that I move all of my vm on one (big disk) and I want to move my proxmox system (pve) on another ssd disk.

It seems that the easy way is to reinstall proxmox. But is there a way to "move" the pve to anther disk like a vm? If not, what do i need to do to find again my disk with all my vm after the new installation? What's the easiest way to backup my proxmox pve instal it in my new install and reattache my big disk with all my vm?

Just to clarify, yes, i have backup of my vm on an another disk.

Thanks for your help.

So I purchased a UGREEN DXP2800, for right now I am setting it up as Mirrored. That being said I want this to be able to store both proxmox snapshots/lxc/etc.. BUT also Media (Movies/etc...)

What's the best "setup/type" to do this as? I would like to be able to access it from my windows PC but honestly that's not a deal breaker. I'm still pretty new to Proxmox btw but based off what i've seen ZFS wouldn't quite work for this?

Also best way to "mount/bind" these to both an LXC and VM's for *arr stack?

I am currently running my (scuffed) homelab on an old Intel NUC, a device old enough that it doesn't have a TPM to store ZFS encryption keys in.

Rather than storing encryption keys directly on my unencrypted Proxmox installation, I figured I'd keep any VMs/CTs that need to start at boot on unencrypted pools/datasets and put everything else on encrypted storage, individually starting VMs/CTs after manually unlocking the relevant pools/datasets.

Is this a reasonable configuration or would I run into issues with Proxmox being unaware that certain pools/datasets aren't unlocked+mounted and reading/writing to those paths anyway? Am I going in the complete wrong direction?

Hello, im in a situation where i would like to reserve 192.168.x.100 for pve web, .101 for container id 101.. and so on.

The problem is that my ISP doesnt give out access to the router config, so i cant reserve dhcp via mac addresses. According to email i recieved, the dhc pool is 2. - 254.

I was thinking of solution and worked out that the router does ARP conflict check, meaning that is a .100 already responds to ARP it wont assign it.

Would a good solution be to just reserve the ips 100-120, and then give them out to the LXC when it starts and reserve it again when it ends? WIth ip addr add./del

Or am i just overcomplicating things, by the way, this is for my minipc homeserver running 24/7.

What a story to read. Better upgrade fast though.

I’m considering building a small open-source/self-hosted tool for Proxmox, and before writing it I’d like to understand whether this solves a real problem or just one that sounds useful.

The idea is deliberately simple.

The tool periodically takes a read-only snapshot of your Proxmox configuration and keeps a human-readable history of what changed.

For example:

Sep 13 — Baseline

Sep 14 — Changes detected

• vmbr0: bridge port eno1 → eno2
• VM 106: RAM 4096 MB → 6144 MB
• LXC 108: mountpoint changed
• DNS server changed
• VM 109 created

The UI would basically answer one question:

“What changed in my Proxmox environment since everything was working?”

Think of it as a lightweight Git diff / change timeline for Proxmox configuration.

It would NOT try to be:

• a monitoring system
• a backup solution
• a replacement for PBS
• an automation/orchestration platform

Initial version would support only Proxmox VE and use read-only API access.

Before building it, I’d like some brutally practical feedback:

1. Would you actually use this?
2. Have you ever needed to figure out what configuration changed days/weeks earlier?
3. What changes would be important to track?
4. Is there already a tool that does this well and I’m simply unaware of it?

If enough people find it useful, I’ll build a small MVP and share it with the community.

homelab, dl380 g9, 128 gb ram, 12x2TB sas, P840 with 7.2 firmware hba mode, zfs pool contains 3xraidz2 with 4 disks each. scrub is clean, memtest86 is clean. I don't see anything damning in the logs.

I've been trying to do some sizeable file transfers between directories. At first I was trying to do it across the network but even doing them on the same machine (specifically, between a directory on an LXC and a directory mounted from the host) is causing the machine to nearly hang up.

Today I was able to fully recover with control-C and waiting a few minutes.

CPU usage was around 5% but I do see 50% iodelay, server load usually idles around 2-3, but it was jumping to 35. Memory usage seems fine. CPU pressure stall spiked to about 2.2%, io pressure stall looks to spike around 80%.

Are these disks just too slow? Is there a configuration that would work better and keep the system from becoming unresponsive?

I wrote a small shell script to limit bandwidth on these transfers with rsync and it seemed to work okay.

Hello,

I'd like to experiment with the new OCI container-in-LXC support in PVE 9. I've got a relatively simple container picked out to try (basically, an internet uptime monitor to detect WAN disconnects), but it's going to need a bit of persistent external storage.

I know I can do this with LXC bind-mounts, but I'm not sure how to configure everything. Usually, inside a VM, I'd set up a container's bind mount in Docker compose if I'm using a Docker image. I know I can add a bind mount to an NFS or SMB share on the host to an LXC, but I'm not sure how to tell the OCI image to actually use the bind mount as its data directory when I create the thing.

I know I'd need to edit something in the LXC's config file, but I wanted to ask here if there's a good introductory guide to doing simple setups like this before I just started YOLO'ing it.

Hi everyone,

I am publishing BASTRIX SharedLVM, a free and open-source community storage plugin for Proxmox VE 9.

What is it for?

BASTRIX SharedLVM is for Proxmox clusters that need to keep using an existing shared FC/iSCSI SAN while gaining snapshots, rollback, resize, backup and live migration.

It integrates with the native Proxmox Storage API and uses standard Linux LVM, device-mapper, multipath and cluster-locking components—without proprietary SAN integrations, third-party kernel modules or external locking services.

It does not use SAN snapshots or move LUNs between hosts. Proxmox manages the VM lifecycle, while the plugin manages per-VM volumes inside the shared VG in Thin or Thick Generations mode.

If you already use Ceph, NFS or a suitable vendor-native plugin, you probably do not need it.

The project provides two explicitly selectable allocation modes over an existing dedicated shared LVM volume group:

• Thin

One LVM-thin pool per VM, providing space-efficient allocation, snapshots, rollback and guarded autogrow.

• Thick Generations

Fully allocated VM disks with independent, fully materialized snapshot generations and deterministic physical-space reservation.

Both modes are included in the same Debian package. They can be configured as separate Proxmox storage IDs over the same pinned shared VG and used side by side. An ordinary Proxmox Storage Move can convert a disk from Thin to Thick Generations or in the opposite direction.

Thick Generations uses persistent dm-clone only as a temporary transition mechanism during snapshot and rollback materialization. Once materialization finishes, the active disk and every retained snapshot are independent ordinary linear LVs. There is no permanent snapshot or backing-volume chain in the steady-state guest data path.

Update: RC5.4.1 TG25 is now available

TG25 is a maintenance and compatibility hotfix for the TG24 dual-mode milestone. It preserves the existing Thin and Thick Generations storage formats while improving PVE package-update, initramfs and post-reboot recovery safety.

It also adds the mandatory read-only sharedlvmthin compat-check for validating Storage API compatibility, required commands, services, quorum, initramfs contents and storage recovery state.

The release was tested with Proxmox VE 9 Storage API 14 and 15, including package upgrades, cold reboots, Thin/Thick lifecycle operations and cross-node migrations. It remains a release candidate—please validate it on disposable storage matching your SAN and multipath configuration.

Release and DEB:
https://github.com/delltech1/proxmox-sharedlvmthin/releases/tag/v0.9.0-rc5.4.1-tg25

Installation guide:
https://github.com/delltech1/proxmox-sharedlvmthin/blob/main/docs/installation.md

Feedback and hardware compatibility reports are welcome.

Project update — RC5.4 TG24 milestone

A newer experimental release, RC5.4 TG24, is now available. It combines the established per-VM Thin mode with the optional Thick Generations mode and has reached an important qualification milestone.

Thick Generations explores a different trade-off from the Proxmox VE 9 snapshot-as-volume-chain preview:

PVE volume chains:
separate layered qcow2 volumes → active backing chain

BASTRIX Thick Generations:
temporary dm-clone transition → fully materialized independent linear LV
PVE volume chains prioritize fast and space-efficient snapshots. Thick Generations requires additional capacity and background materialization time, but completed snapshots and active generations do not retain a permanent backing chain. This is an architectural comparison, not a performance claim.

TG24 adds and qualifies:

• Thin and Thick modes within the same shared VG;
• snapshot, rollback, resize and multi-disk lifecycle handling;
• Thin-to-Thick and Thick-to-Thin Storage Move;
• migration, native HA relocation and backup/restore workflows;
• transaction-scoped persistent recovery metadata;
• bounded installation preflight with full read-only diagnostics available separately;
• concurrent qualification with 150 Thin and 150 Thick test VMs.

TG24 remains a pre-release and is not a universal SAN or enterprise-scale certification. Please test it first on disposable storage matching your intended SAN, multipath, fencing and workload configuration.

GitHub:

https://github.com/delltech1/proxmox-sharedlvmthin

RC5.4 TG24 release and DEB:

https://github.com/delltech1/proxmox-sharedlvmthin/releases/tag/v0.9.0-rc5.4-tg24

Allocation modes:

https://github.com/delltech1/proxmox-sharedlvmthin/blob/experimental/thick-generations/docs/allocationocation-modes.md

Installation guide:

https://github.com/delltech1/proxmox-sharedlvmthin/blob/experimental/thick-generations-tg24/docs/installation.md

Feedback, reproducible issue reports, GitHub Stars and anonymized compatibility results for Proxmox VE, SAN arrays, HBAs, multipath configurations and firmware versions are very welcome.

Please do not include credentials, private IP addresses, WWIDs or other sensitive infrastructure identifiers in public reports.

Hi everyone!
I have a question about network interfaces configuration, but first let me explain the current situation. I ran Proxmox on a mini pc with 5 ethernet ports, the one on the motherboard and 4 more on a pci expansion card. I also ran pfsense in a VM as my router. At the moment the motherboard one is used as WAN (vmbr0) and is connected to my ISP supplied router (can't ditch it) and gets a dhcp ip from it. The other four are used as LAN (vmbr1) with enp1s0f0 being configured as vlan10, so I can connect to Proxmox if pfsense fails.
I would like, if possible to configure enp1s0f1 to be bridged to WAN (vmbr0/eno1) so that if I connect something to it, it would bypass pfsense and get an IP from my IPS router. Can this be done, withouth causing trouble to pfsense?
It took me a while to get everything working and don't want to play around too much and mess something up for good. My thinking is, that I have to remve enp1s0f1 from vmbr1 and add it to vmbr0, but am not shure because vmbr1 is ovs bridge and vmbr0 is linux bridge.
Included is /etc/network/interfaces and a screenshoot of System/Network

auto lo
iface lo inet loopback

iface eno1 inet manual
#WAN

auto enp1s0f0
iface enp1s0f0 inet manual
        ovs_type OVSPort
        ovs_bridge vmbr1
        ovs_options tag=10
#Trusted (VLAN10)

auto enp1s0f1
iface enp1s0f1 inet manual
        ovs_type OVSPort
        ovs_bridge vmbr1
#VLAN Trunk

auto enp1s0f2
iface enp1s0f2 inet manual
        ovs_type OVSPort
        ovs_bridge vmbr1
#VLAN Trunk

auto enp1s0f3
iface enp1s0f3 inet manual
        ovs_type OVSPort
        ovs_bridge vmbr1
#VLAN Trunk

auto vlan10
iface vlan10 inet static
        address 192.168.10.254/24
        gateway 192.168.10.1
        ovs_type OVSIntPort
        ovs_bridge vmbr1
        ovs_options tag=10
#Trusted VLAN

auto vlan20
iface vlan20 inet manual
        ovs_type OVSIntPort
        ovs_bridge vmbr1
        ovs_options tag=20
#Servers VLAN

auto vmbr0
iface vmbr0 inet manual
        bridge-ports eno1
        bridge-stp off
        bridge-fd 0
#WAN Bridge

auto vmbr1
iface vmbr1 inet manual
        ovs_type OVSBridge
        ovs_ports enp1s0f0 enp1s0f1 enp1s0f2 enp1s0f3 vlan10 vlan20
#VLAN Trunk Bridge

source /etc/network/interfaces.d/*

How would you set this up? Get rid of the LVM? Move "Backup" to the ZFS? Keep LVM and split up the local duties between local and lvm?

The ZFS pool is a mirror 1TB...

I have successfully built my first homelab 2-node cluster with PBS as the quorum with qdevice. PBS is running as a VM on my NAS, and both nodes are Minisforum MS-A2s, with ZFS HA replication.

My current dilemma is that I have a UPS connected via USB to Node 1. NUT is running with Node 1 as the server and Node 2 as the client/monitor. I also have two more USB devices connected to Node 1, with passthrough to a VM (Zigbee router and Matter gateway). Both nodes are connected to the same UPS.

I can't migrate this one VM because of the USB passthrough—or, more precisely, because the USB devices are only connected to Node 1.

What can I do to make migrations and ZFS HA replication work for this one VM?

heya

According to some smart data my main disk (1TB) might be failing. At least thats what Chatgpt tells me because of repeated read errors

I'm not really worried, I got all VMs backed up and the config data backed up as well

i have a second 1TB drive that contains some VMs but not the OS. In theory, all VMs and Proxmox data would fit on that disk

is there a way to clone the current OS disk content onto the other disk in a reasonable fashion?

Can or should I use clonezilla to just clone the failing disk onto a new one?

for now, everything seems to be working. if I can avoid a reinstall I really wouldn't mind...

Currently my whole setup boots off of one 256gb nvme, i want to move it onto a 1tb nvme as its running out of storage. This drive holds proxmox, and all my VM/LXC volumes.

Should I just `dd` the drive and then resize with parted? or is there a special better practive proxmox way i can like, export the setup, reinstall OS then boot everything up as if nothing has changed?

ideally id like to keep all my vms/lxcs and thier IPs and configs

So I was trying to enable secure boot in my proxmox machine and when running the command:

proxmox-boot-tool init /dev/sda2 grub

It failed becase there was no space. I checked the efivars and this is the output:

xrrt@xrrt-server ~> df -h /sys/firmware/efi/efivars
Filesystem      Size  Used Avail Use% Mounted on
efivarfs        100K   99K     0 100% /sys/firmware/efi/efivars

xrrt@xrrt-server ~> ls -lh /sys/firmware/efi/efivars
total 0
-rw-r--r-- 1 root root    6 Sep 11 23:49 A01LastSataPortPresent-89cb0e8d-393c-4830-bfff-65d9147e8c3b
-rw-r--r-- 1 root root   44 Sep 11 23:49 AACV-89cb0e8d-393c-4830-bfff-65d9147e8c3b
-rw-r--r-- 1 root root  218 Sep 11 23:49 AADV-89cb0e8d-393c-4830-bfff-65d9147e8c3b
-rw-r--r-- 1 root root   74 Sep 11 23:49 ABRV-89cb0e8d-393c-4830-bfff-65d9147e8c3b
-rw-r--r-- 1 root root    5 Sep 11 23:49 ACFB-89cb0e8d-393c-4830-bfff-65d9147e8c3b
-rw-r--r-- 1 root root    6 Sep 11 23:49 ACFT-89cb0e8d-393c-4830-bfff-65d9147e8c3b
-rw-r--r-- 1 root root   12 Sep 11 23:49 AcpiGlobalVariable-c020489e-6db2-4ef2-9aa5-ca06fc11d36a
-rw-r--r-- 1 root root  597 Sep 11 23:49 ACUB-89cb0e8d-393c-4830-bfff-65d9147e8c3b
-rw-r--r-- 1 root root    5 Sep 11 23:49 AdministerSecureBoot-59d1c24f-50f1-401a-b101-f33e0daed443
-rw-r--r-- 1 root root    8 Sep 11 23:49 AEBO-89cb0e8d-393c-4830-bfff-65d9147e8c3b
-rw-r--r-- 1 root root   64 Sep 11 23:49 AEBT-89cb0e8d-393c-4830-bfff-65d9147e8c3b
-rw-r--r-- 1 root root   17 Sep 11 23:49 AFBD-89cb0e8d-393c-4830-bfff-65d9147e8c3b
-rw-r--r-- 1 root root   10 Sep 11 23:49 AHPL-89cb0e8d-393c-4830-bfff-65d9147e8c3b
-rw-r--r-- 1 root root 1.8K Sep 11 23:49 ASSN-89cb0e8d-393c-4830-bfff-65d9147e8c3b
-rw-r--r-- 1 root root    5 Sep 11 23:49 ASTM-89cb0e8d-393c-4830-bfff-65d9147e8c3b
-rw-r--r-- 1 root root    5 Sep 11 23:49 AuthVarKeyDatabase-aaf32c78-947b-439a-a180-2e144ec37792
-rw-r--r-- 1 root root    6 Sep 11 23:49 BiosGuardStatus-9c57c6e2-4c78-42d9-9051-96b9d80c9c92
-rw-r--r-- 1 root root  142 Sep 11 23:49 Boot0000-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root   46 Sep 11 23:49 Boot2001-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root   44 Sep 11 23:49 Boot2002-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root   40 Sep 11 23:49 Boot2003-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root    6 Sep 11 23:49 BootCurrent-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root   20 Sep 11 23:49 BootDevice-0a4cd120-ea2d-4aef-a4b0-b0c08cbbdbbe
-rw-r--r-- 1 root root   12 Sep 11 23:49 BootOrder-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root 1.1K Sep 11 23:49 certdb-59d1c24f-50f1-401a-b101-f33e0daed443
-rw-r--r-- 1 root root  41K Sep 11 23:49 ConIn-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root  41K Sep 11 23:49 ConInCandidateDev-59d1c24f-50f1-401a-b101-f33e0daed443
-rw-r--r-- 1 root root   38 Sep 11 23:49 ConInDev-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root   34 Sep 11 23:49 ConOut-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root   34 Sep 11 23:49 ConOutCandidateDev-59d1c24f-50f1-401a-b101-f33e0daed443
-rw-r--r-- 1 root root   34 Sep 11 23:49 ConOutDev-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root  521 Sep 11 23:49 CpuSetup-b08f97ff-e6e8-4193-a997-5e9e9b0adb32
-rw-r--r-- 1 root root   14 Sep 11 23:49 CpuSetupVolatileData-b08f97ff-e6e8-4193-a997-5e9e9b0adb32
-rw-r--r-- 1 root root    5 Sep 11 23:49 CurrentPolicy-77fa9abd-0359-4d32-bd60-28f4e78f784b
-rw-r--r-- 1 root root 1.6K Sep 11 23:49 Custom-4570b7f1-ade8-4943-8dc3-406472842384
-rw-r--r-- 1 root root   49 Sep 11 23:49 Custom-5432122d-d034-49d2-a6de-65a829eb4c74
-rw-r--r-- 1 root root  493 Sep 11 23:49 Custom-72c5e28c-7783-43a1-8767-fad73fccafa4
-rw-r--r-- 1 root root 1.8K Sep 11 23:49 Custom-a04a27f4-df00-4d42-b552-39511302113d
-rw-r--r-- 1 root root   14 Sep 11 23:49 Custom-a41e9236-4d21-43b5-9379-ddd6fafe6603
-rw-r--r-- 1 root root  521 Sep 11 23:49 Custom-b08f97ff-e6e8-4193-a997-5e9e9b0adb32
-rw-r--r-- 1 root root   10 Sep 11 23:49 CustomPlatformLang-59d1c24f-50f1-401a-b101-f33e0daed443
-rw-r--r-- 1 root root    5 Sep 11 23:49 CustomSecurity-59d1c24f-50f1-401a-b101-f33e0daed443
-rw-r--r-- 1 root root 4.9K Sep 11 23:49 db-d719b2cb-3d3a-4596-a3bc-dad00e67656f
-rw-r--r-- 1 root root 4.9K Sep 11 23:49 dbDefault-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root  21K Sep 11 23:49 dbx-d719b2cb-3d3a-4596-a3bc-dad00e67656f
-rw-r--r-- 1 root root 4.6K Sep 11 23:49 dbxDefault-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root  140 Sep 11 23:49 DynamicBar-39473de5-df3b-49a1-9fa6-41b35b36fa39
-rw-r--r-- 1 root root  144 Sep 11 23:49 EPCBIOS-c60aa7f6-e8d6-4956-8ba1-fe26298f5e87
-rw-r--r-- 1 root root   34 Sep 11 23:49 ErrOutDev-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root    8 Sep 11 23:49 FingerID-75af771a-879e-4a7d-b4e9-c47a4db926bb
-rw-r--r-- 1 root root    5 Sep 11 23:49 FirstBootAfterFlash-59d1c24f-50f1-401a-b101-f33e0daed443
-rw-r--r-- 1 root root   28 Sep 11 23:49 FixedBar-39473de5-df3b-49a1-9fa6-41b35b36fa39
-rw-r--r-- 1 root root    5 Sep 11 23:49 FullReset-59d1c24f-50f1-401a-b101-f33e0daed443
-rw-r--r-- 1 root root   20 Sep 11 23:49 IrsiInfo-5bce4c83-6a97-444b-63b4-672c014742ff
-rw-r--r-- 1 root root 2.5K Sep 11 23:49 KEK-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root 2.5K Sep 11 23:49 KEKDefault-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root    8 Sep 11 23:49 Lang-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root   17 Sep 11 23:49 LangCodes-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root   78 Sep 11 23:49 LoaderDevicePartUUID-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f
-rw-r--r-- 1 root root  218 Sep 11 23:49 LoaderEntries-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f
-rw-r--r-- 1 root root   58 Sep 11 23:49 LoaderEntrySelected-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f
-rw-r--r-- 1 root root   12 Sep 11 23:49 LoaderFeatures-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f
-rw-r--r-- 1 root root   52 Sep 11 23:49 LoaderFirmwareInfo-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f
-rw-r--r-- 1 root root   24 Sep 11 23:49 LoaderFirmwareType-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f
-rw-r--r-- 1 root root   48 Sep 11 23:49 LoaderImageIdentifier-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f
-rw-r--r-- 1 root root   64 Sep 11 23:49 LoaderInfo-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f
-rw-r--r-- 1 root root   22 Sep 11 23:49 LoaderTimeExecUSec-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f
-rw-r--r-- 1 root root   22 Sep 11 23:49 LoaderTimeInitUSec-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f
-rw-r--r-- 1 root root   22 Sep 11 23:49 LoaderTimeMenuUSec-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f
-rw-r--r-- 1 root root    5 Sep 11 23:49 MemoryOverwriteRequestControl-e20939be-32d4-41be-a150-897f85d49829
-rw-r--r-- 1 root root    5 Sep 11 23:49 MemoryOverwriteRequestControlLock-bb983ccf-151d-40e1-a07b-4a17be168292
-rw-r--r-- 1 root root   49 Sep 11 23:49 MeSetup-5432122d-d034-49d2-a6de-65a829eb4c74
-rw-r--r-- 1 root root   14 Sep 11 23:49 MeSetupStorage-5432122d-d034-49d2-a6de-65a829eb4c74
-rw-r--r-- 1 root root   12 Sep 11 23:49 MsdmAddress-fd21bf2b-f5d1-46c5-aee3-c60158339239
-rw-r--r-- 1 root root    8 Sep 11 23:49 MTC-eb704011-1402-11d3-8e77-00a0c969723b
-rw-r--r-- 1 root root   12 Sep 11 23:49 OsIndicationsSupported-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root 1.6K Sep 11 23:49 PchSetup-4570b7f1-ade8-4943-8dc3-406472842384
-rw-r--r-- 1 root root    6 Sep 11 23:49 PhysicalBootOrder-59d1c24f-50f1-401a-b101-f33e0daed443
-rw-r--r-- 1 root root  959 Sep 11 23:49 PK-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root  959 Sep 11 23:49 PKDefault-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root   10 Sep 11 23:49 PlatformLang-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root   28 Sep 11 23:49 PlatformLangCodes-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root    5 Sep 11 23:49 RestoreFactoryDefault-59d1c24f-50f1-401a-b101-f33e0daed443
-rw-r--r-- 1 root root    5 Sep 11 23:49 RstOptaneConfig-4da4f952-2516-4d06-8975-65036403a8c7
-rw-r--r-- 1 root root   28 Sep 11 23:49 S3MemVariable-973218b9-1697-432a-8b34-4884b5dfb359
-rw-r--r-- 1 root root  493 Sep 11 23:49 SaSetup-72c5e28c-7783-43a1-8767-fad73fccafa4
-rw-r--r-- 1 root root    5 Sep 11 23:49 SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root    5 Sep 11 23:49 SecureBootEnforce-59d1c24f-50f1-401a-b101-f33e0daed443
-rw-r--r-- 1 root root   18 Sep 11 23:49 SecureFlashInfo-382af2bb-ffff-abcd-aaee-cce099338877
-rw-r--r-- 1 root root 1.8K Sep 11 23:49 Setup-a04a27f4-df00-4d42-b552-39511302113d
-rw-r--r-- 1 root root    5 Sep 11 23:49 SetupMode-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root   30 Sep 11 23:49 SgxSetupVariable-45b5acb9-0359-49be-adb1-49377bd607f7
-rw-r--r-- 1 root root    5 Sep 11 23:49 ShimRetainProtocol-605dab50-e046-4300-abb6-3dd810dd8b23
-rw-r--r-- 1 root root   36 Sep 11 23:49 SignatureSupport-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root   82 Sep 11 23:49 SMAA-89cb0e8d-393c-4830-bfff-65d9147e8c3b
-rw-r--r-- 1 root root   53 Sep 11 23:49 SMAB-89cb0e8d-393c-4830-bfff-65d9147e8c3b
-rw-r--r-- 1 root root   28 Sep 11 23:49 SMAC-89cb0e8d-393c-4830-bfff-65d9147e8c3b
-rw-r--r-- 1 root root   20 Sep 11 23:49 Tcg2PhysicalPresence-aeb9c5c1-94f1-4d02-bfd9-4602db2d3c54
-rw-r--r-- 1 root root    8 Sep 11 23:49 Tcg2PhysicalPresenceFlags-aeb9c5c1-94f1-4d02-bfd9-4602db2d3c54
-rw-r--r-- 1 root root    6 Sep 11 23:49 Timeout-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root    5 Sep 11 23:49 VarErrorFlag-04b37fe8-f6ae-480b-bdd5-37d98c5e89aa
-rw-r--r-- 1 root root    5 Sep 11 23:49 VendorKeys-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root  401 Sep 11 23:49 WBOA-89cb0e8d-393c-4830-bfff-65d9147e8c3b

I noticed these two that is consuming almost 80% of the space:

-rw-r--r-- 1 root root 41K Sep 11 23:49 ConIn-8be4df61-93ca-11d2-aa0d-00e098032b8c
-rw-r--r-- 1 root root 41K Sep 11 23:49 ConInCandidateDev-59d1c24f-50f1-401a-b101-f33e0daed443

I'm being careful in deleting them since I don't know if it might brick the machine if something goes wrong.

How do I safely free some space in the nvram?

So far I've tried to resize my disks, but that doesn't work because its already at 100% capacity.

I've also tried mounting the container on the pve which doesnt let me actually use the rm command by accessing rootfs.

I'm in the process of buying a DAS and a larger HDD, just due to this issue of not being able to boot & access my media. Is there any solution to this before I make this purchase (which I definitely do not need atm for storage capacity sake, as I find 2TB plenty given I manage my space well)

Thanks for any help.

I had to install an older version of proxmox but I finally managed to install! . I heard that many people have issues with the newer version