Search results

Also had this error, quite easy to reproduce if you set the same schedule for pruning and gc on a datastore (eg, "daily" for both)

I think the only way is to restore the vzdump archive on a PVE host, and then backup the restored VM on PBS

You can take a look at the files here : https://git.fws.fr/fws/ansible-roles/src/branch/master/roles/sssd_ad_auth/templates (the various deb_xxx files). I'm using those to auth my PVE hosts against a Samba4 domain with sssd. Cheers, Daniel

You can use zfs and set quota on dataset

You can still enable stp in /etc/network/interfaces if so you want. All the SDN stuff, including l3 routing are for situations where simple bridges are not an option (eg, when you do not control the l2 between your nodes, so no VLAN. Or when your hostser doesn't provides QinQ etc.)

I do not understand. You can't do it, but you've done it ? That doesn't make a lot of sens. You can't do it through the GUI ? Well, it's an advanced options most users will never need to understand or set. You can always set it in /etc/network/interfaces manually

Well, you have saturated your LVM thin storage. You have to free some space (either extend the thin pool, or remove some of the volumes) before trying to recover data inside VM.

There's no one true and best way to do this. Depends on a lot of factors. Including if you have another temp storage available, how much downtime you can afford, the size of the disks etc. You can for example do offline migrations with qm importdisk. It'll convert from vmdk to raw while copying...

I don't understand your question With a san, I'd use lvm over iscsi.

One way to have a managed storage is to stack LVM on top of your iSCSI device. Note that such a setup would provide a block based storage, so not usable for files (no template/ISO/snippets, nor backup dumps). Also, while the storage can be shared accross all your nodes, it doesn't support thin...

Hardware spec can be different, no problem

The 3rd node can be replaced with another qdevice to provide the needed vote. See https://pve.proxmox.com/wiki/Cluster_Manager

You need 3 nodes yo have HA working

An update has been pushed with a fix for this. See https://bugzilla.proxmox.com/show_bug.cgi?id=2719

Well, depends on your needs. I'll personnaly always favor iSCSI+LVM over NFS (for performance, and reliability reasons). Block based storage are usualy preferred. But, with NFS, you can use qcow2, so thin prov and snapshots.

You need to configure the multipath device in /etc/multipath.conf. And exclude the underlying devices from LVM, so that LVM only use the multipath "view". See https://pve.proxmox.com/wiki/ISCSI_Multipath

If it's an NFS export from a ZFS dataset, it's probably because since ZFS on Linux 0.8.3, the no_root_squash option isn't set anymore by default, and must be set explicitely, like zfs set sharenfs='rw,no_root_squash' zpool/foo/bar

The issue is most likely the change in zfs 0.8.3 : default nfs exports do not set no_root_squash anymore. You must set it explicitely now, eg zfs set sharenfs='rw,no_root_squash' zpool/dataset

This is due to padding when using small volblocksize with raidz. See https://www.reddit.com/r/zfs/comments/b6dm4y/raidz2_used_size_double_logical_size_in_proxmox_53/?utm_source=amp&utm_medium=&utm_content=post_body for example. Try using 16k volblocksize (or whatever best value for your raidz...

You should Indeed reboot to run the latest kernel anyway. But I recommend to do so after feeeing some space and reinstalling the latest kernel, to be sure