Recent content by Spinning_rust

UPDATE I found the solution to my problem: it was the keyname I used, the wrong value for the zone field and the API for some reason, the knot plugin type does not work, but the generic "nsupdate (RFC 2136)" does So what made it all work: knot.conf key: - id: proxmox-acme algorithm...

no, I only have one PVE node and KnotDNS as well as OpenBao is also standalone if that matters.

Hi there, I'm trying to set up a PKI for certificates in my homelab with OpenBao and Knot DNS. I'm running my own DNS because I use my own TLD. What I'm trying to do is using the Proxmox ACME setup to automatically get certificates from my OpenBao with the ACME DNS-01 challenge. When using the...

i restored some VMs with older backups and that "solved" the issue, as theyre now booting up again. I'm still curious how exactly the upgrade (or whatever else happened at this time) broke the VM disks because the VMs were 100% working before i powered them off for the upgrade. Hopefully it...

Yeah I think I have an older backup, I could try that tomorrow when I’m back in the Office about the command, no i just changed the filename (?) to vmdisk 106-0 But it‘s still weird, it‘s like the new version of qemu isn’t compatible with the „old“ disk format or something

No, he was using old laptops and single disk zfs pool as a storage backend for VMs and containers

Yep, i had to change your command slightly but i got the vmdisk 106: root@top:~# lsof /dev/mapper/PLS-vm--106--disk--0 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME fdisk 281530 root 3u BLK 253,8 0t2098176 604 /dev/mapper/../dm-8

No, there were not any changes to the storage... Whats also strange, a friend has the exact same issues with PVE community edition and local storage after a Proxmox 6 --> 7 in place upgrade. So my setup here is is the second one i see with this behavior root@top:~# lvs LV VG Attr...

weirdly enough, the one VM i used all the time (VMID 100) does not show up here (see dev-mapper.txt). But when I tried to list the partitions for VMID 106 (Ubuntu VM with the same symptoms as described throughout this thread, just on another node i also upgraded from 6 --> 7) i get the output...

i live-booted into a debian shell from the netinstall iso and according to fdisk (sgdisk wasnt on board), there are no recognized partitions on this disk Should i try again with the "proper" debian live image and sgdisk?

Update: after some external storage and nework tweaking i could finally make a backup. Restoring a new vm disk with this backup resulted in another "no bootable Device found" message in the Proxmox bios on VM startup.

Good morning again, I started the backup of the VM towards the PBS yesterday and for some reason, the read speed is at maximum 4MB/s; mostly around a few hundred KB/s. The storage is an external iSCSI attached HP MSA 2040 disk shelf but all other disk intensive tasks like installing a new VM...

Yes, i was using jumbo frames and yes, using normal frames resolved the issue :D The switch probably was not properly configured and causing the issue Thanks a lot for the support, i'm marking this thread as solved.

Just checked all of that: - iptables was not installed in the first place on PBS, therefore iptables-save did not yield any output - The Cluster and the PBS is only connected via a Juniper switch and 10G DAC cables; the traffic is contained in a VLAN on this switch. There's also definitively no...

I migrated this VM to the one node that is able to connect to the PBS and running a backup now. it's excruciatingly slow; so maybe this one has issues as well :( I'll wait until it either finishes or fails.