Search results

We're also testing the new Fabrics GUI and we see exactly the same behaviour with pings, even with a single fabric. Tested lots of different configurations, and the only one that makes it stable is setting node's /32 ip address to every interface that belong to the fabric, as per @ggoller...

I understand. To me, it seems these are two different approaches to avoid running out of space. With quotas, one just needs to make sure other datasets don’t consume all the available space (that’s why I apply quotas to all datasets). Otherwise, write operations may fail (even if the quota is...

Why not use zfs quota? Maybe I'm missing something, but seems like a simpler approach to me (see: https://forum.proxmox.com/threads/proxmox-backup-server-3-1-2-set-zfs-quotas.139917/post-625317). I set up a quota for each dataset and call it a day.

Have you tried by recreating the EFI disk? https://forum.proxmox.com/threads/vm-reboot-issue-vm-stuck-on-proxmox-start-boot-option-screen.154925/post-712527

As per the documentation[0]: Adding/Deleting Nodes After QDevice Setup If you want to add a new node or remove an existing one from a cluster with a QDevice setup, you need to remove the QDevice first. After that, you can add or remove nodes normally. Once you have a cluster with an even node...

Hi, vlan111 has an incorrect vlan-raw-device. It should be vmnetbr, not vlan111 itself. Currently, vlan111 is not linked to the physical interface through the bridge, so it won’t work.

Maybe you're hitting this bug: https://forum.proxmox.com/threads/veeam-silent-data-corruption.155212/post-718208, have you tried with the last version of PVE plugin for Veeam?

You have to click on "Reissue" in order to free the license from the old server. Then, add it to the new server.

As @itNGO said, I've recreated EFI disk and it worked. I've also tried to recreate TPM state, but with EFI disk was enough. The only thing that bothers me is why the VM boots one time after restore from backup and then refuses to boot...

Same here, fortunately it is happening on a virtualized test cluster. I've restored a Windows 2019 VM from a backup to local-zfs, it booted the first time, moved it to Ceph storage and from the second boot onwards it got stuck at "Start boot option...", with VM's CPU at 100%. Just to make...

This change affected to enterprise users too, so even with a subscription you would be in the same situation. In fact, the change it's not Proxmox related but kernel related. I get your point, maybe a warning before upgrading in case of breaking changes could be useful.

It is worth to check "breaking changes" section in the Roadmap everytime a new major/minor version of Promxox is released, just in case some issues like that arise. In this case, a workaround was to pin network interface names based on its mac address...

Hi! Check breaking changes for the latest kernel: https://pve.proxmox.com/wiki/Roadmap#Proxmox_VE_8.2 Boot with the newest kernel and check your interface names. If a p0 has been added to the end of the interfaces, change its name in /etc/network/interfaces (backup this file before doing the...

Thanks for pointing that out, I wasn't aware of this option and I thought it was the same as with volblocksize.

Unfortunately you will need to backup and recover your VMs to be able to benefit from thin provisioning. Another option is to move disks to a non-zfs storage and then move them back to your ZFS pool.

You should be able to select an older kernel going to Advanced Options on the Grub blue screen,as esi_y said:

Are you able to boot with an older kernel? If so, you may be affected with one of the breaking changes in PVE 8.2. You can check them here: https://pve.proxmox.com/wiki/Roadmap#Proxmox_VE_8.2

It seems your disk is starting to fail, since logs show Raw_Read_Error_Rate and Hardware_ECC_Recovered values are increasing. I would definitely replace the disk. Don't use apt-get upgrade. Use always apt dist-upgrade to avoid dependency problems.

Timestamp of last_sync and last_try is expressed in Unix time format [0] [1]. In your script, you could store the timestamp before you start the snapshot with schedule_now , and when the snapshot is done check if last_sync value is greater than the one you've stored. Checking fail_count would...

You can do it through scripting, using the API from the node itself (pvesh) https://pve.proxmox.com/pve-docs/api-viewer/#/nodes/{node}/replication/{id} An option would be to launch the replication using schedule now and then check its status through status.