Blog Inforeseau.com – Alexandre Blanc Cyber Security

Proxmox – ZFS – Dead drive on active VM, recover from replicated disk

So you run a proxmox cluster, and you have 3 nodes.

Your VMs are all replicated, using ZFS replication, and in HA mode.

Each ZFS volume runs on a single drive, because we don’t have too much money, and it’s an home setup, OR, your RAID back end went nuts and you lost a full physical volume.

Issue is, your VM did not migrate through HA to another node, because obviously, the PVE node was not down, as only 1 of the ZFS drives died.

Then, I had major power outage, and a second one, ending after auto reboot, with some VMs on one node, some on another, and, this specific VM (my nextcloud), with a 1TB virtual disk, that was on the dead physical disk.

At this stage, I have a failed VM, on an active node, without valid disk for the VM, BUT, thanks to the cluster, I still see with « zfs list » on the other nodes, that the replicated copies are still here !

So here are the steps, finally easier and faster than expected :

Move the VM manually in another node of the cluster, and this is very simple, as SSH with a shell on any PVE nodes :

mv /etc/pve/nodes/pve1/qemu-server/106.conf /etc/pve/nodes/pve6/qemu-server/

Now, you did it, refresh the web interface, and the VM is now back on the node that has a valid disk for your VM ! …but it won’t start because it was in failed state at HA level. Not an issue, on the VM, menu « more », manage HA, and set it to « disabled », validate. Then again, in the menu, set it to « started ».

VM should start again, using the replica of the disk !

Now, on the node that had the failed disk, I have SATA drives, I just hot unplugged the dead unit, and put a new disk.

Initiate the new disk as GPT, and we’ll need to add it to ZFS. Issue is, volume already exists. So we need to go to « datacenter » then « storage », double click on the needed ZFS Pool, and uncheck the node that had the failed drive.

Validate, and go add the disk on the node, in ZFS, with the same ZFS Pool name.
Now you have valid new ZFS volume.

Make sure your run the replication from the currently running node, to this empty volume !!! So has you have the data replicated again.

I was a bit stressed, even if I have backup on another machine at filesystem level with backuppc of my VM content, it’s always much much much more easy and quick to get the existing VM back on track.

I hope it will help you. I realized at least how easy and simple it is to move a VM that is not running from one host to another.

Have a great day, and go to hell power outage and dead drives ! (Yes I have UPS, surge protection… still).

Restrict access to proxmox web admin interface

When you install proxmox, you have by default access to your admin interface, usually using the following URL :

https://IP-OF-YOUR-INSTANCE:8006

This is totally fine when using an internal instance, but quite another story if you rent an online server with proxmox on it. We don’t want to let this access wide open.

While proxmox comes with a nice firewall, it doesn’t allow you to restrict access to port 8006 and 22 (obviously not to lock you out), because it won’t do this on your « local » network, but when you are on a publicly connected machine, the « local » network is internet.

Therefore, a way to restrict this access is by creating the following file /etc/default/pveproxy with the following content :

ALLOW_FROM="127.0.0.1,172.20.0.1"
DENY_FROM="all"
POLICY="allow"

Be sure to use lower case. Then restart the pveproxy service :

service pveproxy restart

And from now on, only the listed IPs have access to the admin interface.

Reference : https://vdillenschneider.fr/architecture-de-services-avec-proxmox-sur-un-serveur-kimsufi

Migrate your ESXI VMs to proxmox ZFS

Lately, I migrated my personal lab from ESXI to proxmox hypervisor.
Many reasons are behind this move :
– using vmware esxi free did not allow me proper HA or replication
– each update was painful, and got some CPU no longer supported warnings
– not free open source etc.
– saw proxmox running at other place and was looking good
– the need to learn something new, and to have HA at my home lab as I migrated my workloads from VPS to home (due to OVH suspending an old offer and not allowing to migrate, but rather requiring full re install, in short delays…. tired of not controlling anything, I wanted to move my stack home, and have some redundancy).

Basically, this operation was from the following :
ESXI 6.7 latest update available in 2020 April (aside of the new major 7) to Proxmox PVE 6.1.8

This assume you have an ESXI and proxmox up and running that can reach each other and that you have NO SNAPSHOT on vmware esxi.
I also assume you have a ZFS volume mounted in your proxmox.

On the proxmox node (pve), from the shell, I install SSHFS :

#install SSHFS to mount esxi volume
apt install sshfs

#creating mount point
mkdir /mnt/ssh

#Mount root directory of esxi on /mnt/ssh of pve node
sshfs root@esxi:/ /mnt/ssh

#Convert flat VMDK drive to raw image (reading on esxi via SSHFS and output on your local proxmox)
#The below command must run from a drive where you have enough space to store the full size VMDK (usually /volume-you-created on your proxmox)
qemu-img convert /mnt/ssh/vmfs/volumes/<yourdatastore>/<yourvmname>/<yourvmname>-flat.vmkd -O raw <yourvmname>.raw

#Create the target VM in proxmox with the same specs as ESXI, and making sure you pick ZFS volume as storage.
#identify target disk of the created VM in /dev/zvol/<volumeName>/<diskName>

#Once you know where is you new VM (usually a number associated with the VM) volume is you can dump the raw image to the new virtual disk
dd bs=1M if=<yourVMname>.raw of=/dev/zvol/<volumeName>/<diskName>

If your machine is loaded, the command above may stale your ZFS and overload the server ( load can be way above amount of availalbe threads, due to default ZFS settings no limiting amount of threads).

A workaround found here actually helped getting around the issue using the option oflag=direct
dd bs=1M oflag=direct if=<yourVMname>.raw of=/dev/zvol/<volumeName>/<diskName>

Hope this helps, when migrating big VMDKs over 1TB, I had ZFS crashes due to this, command above allows to import them properly.

#When done, start the new VM and see if it boots. The main issue I had either on CentOs or Debian, was that network interface name changed. So at first boot, VM has no network.
#Not a big issue, edit the interface name in /etc/network/interface (debian) or /etc/sysconfig/network-scripts/ifcfg-ethx  (CentOs)
#The MAC address changed, unless you forced it while creating the VM.

#As soon as your VM is up, delete the .raw image from your drive to free up space.

This is how I migrated 8 VMs, from ESXI to Proxmox without any issues.

Additional notes following this migration (2020 April 27) :

After migrating my last VM, I had a weird error stating I did not have enough space to replicate, as the system could not take any snapshot.

This is due to a default setting in ZFS, in Proxmox, where by default, a space reservation on the volume is made for snapshots etc, with the same size of the actual disk size.

While fine for most of the case, when you have a VM with 1.66TB drive, it starts to be an issue.

There is more explanation here about ZFS refreservation : http://www.mceith.com/blog/?p=153

Basically, in my case, the refreservation was as big at 1.66TB, not allowing snapshots to be taken, and therefore, not allowing VM replication.

You can see the information for a volume with the following command :

zfs get refquota,reservation,refreservation yourvolume/your-vm-disk

So basically, for my VM that had a refreservation default value of 1.66TB, I actually did set it to 500G, since my drive only had 578G of unassigned space.

This allowed the replication process to go on :

Hopefully this will help some, facing the disk full issue where disk is not actually full but reserved.