Where are my Proxmox files in a ZFS?

[LnxBil]

Give it a try, works on Linux and OSX without having to be root for me. It's just a list/display command, not modifying anything.

Oh yes, you'r right. Previously, you needed to change a special sudoers file in /etc/sudoers.d/zfs that would allow it. In never ZFS versions, it works out-of-the-box.

 

[ronejamesdo]

I don't, never had to do something like this. I have reasonable expectations that nothing will be wiped out. It's easy to try - give it a shot and report it here for posterity.

---

Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox

For posterity, creating a VM in the GUI after having "dd status=progress if=..." etc does not overwrite the copy. It just creates the new disk as vm-106-disk-1 (presuming the one you copied is vm-106-disk-0). (You still have to "qm disk rescan --vmid 106" though so you don't really gain anything.)

Also, if you have the /etc/pve/qemu-server/ folder backed up somewhere (it only contains files 101.conf 102.conf, etc) you would surely thank yourself in the event of a disaster. These (are conceptually similar to a .vmx file if you are coming from ESXi and) contain the VMs settings (the amount of RAM assigned, CPUs etc). They are actually usable as-is apparently. For example you can copy 102.conf to the next consecutive unused number and edit it to change this line "scsi0: BigDrive:vm-102-disk-0,size=16G" to where you've put your copy and it seems all to just work.

 

[LnxBil]

Also, if you have the /etc/pve/qemu-server/ folder backed up somewhere (it only contains files 101.conf 102.conf, etc) you would surely thank yourself in the event of a disaster. These (are conceptually similar to a .vmx file if you are coming from ESXi and) contain the VMs settings (the amount of RAM assigned, CPUs etc). They are actually usable as-is apparently. For example you can copy 102.conf to the next consecutive unused number and edit it to change this line "scsi0: BigDrive:vm-102-disk-0,size=16G" to where you've put your copy and it seems all to just work.

Of course you can, but why would you want to do that instead of using the API and automation?

 

[ronejamesdo]

Of course you can, but why would you want to do that instead of using the API and automation?

In my imagination what I have is a completely dead Proxmox, a somehow still accessible zfs, and am rebuilding or migrating to a different Proxmox manually (with only access to that zfs), in that I don't remember how much RAM etc each device is supposed to have but 101.conf 102.conf, etc are the actual settings from the dead Proxmox (is my thinking).

(Generally this is a learning exercise and about me feeling capable in the event of some unforeseen catastrophe.)

What do you mean by automation here?

 

[ubu]

ZFS is a complex beast but there is documentation.

Your disks are in one (or more) pools, in that pool you have volumes (filesystems) and blockdevices (zvols)

in case of your dead proxmox server, you just set up a new one, attach your proxmox backup server and restore your vms and containers (you have a proxmox backup server, don't you?

HAVE a hardcopy of your Backup encryption key!

 

[LnxBil]

In my imagination what I have is a completely dead Proxmox, a somehow still accessible zfs, and am rebuilding or migrating to a different Proxmox manually (with only access to that zfs), in that I don't remember how much RAM etc each device is supposed to have but 101.conf 102.conf, etc are the actual settings from the dead Proxmox (is my thinking).

(Generally this is a learning exercise and about me feeling capable in the event of some unforeseen catastrophe.)

What do you mean by automation here?

Okay, in that regard ... automation is just replicating your ZFS pool AND the PVE internal database with all the configuration options. That is a good idea to familiarize yourself with the recovery option there.