Search results

Thanks for the answer. But strange, that the nine working VMs has the same partiion-numbers, because all created from the same template… Udo

Hi, we have an strange effect. On an new migrated VM to an pve8-node, the offline migration of the VM-disk from ceph to local-zfs destroy the target disk. The VM arent boot, because the partitiontable are gone and only the content of /boot are on sda. But we do the same with nine VMs before, and...

sind wahrscheinlich die snapshots?! Am besten die Ausgabe von folgenden Befehlen posten pvs vgs lvs Übrigens halte ich Raid-5 mit 10 16TB-Disk für äußerst gefährlich. Die Chance das bei einem Rebuild die nächste Disk ausfällt ist nicht so gering… Udo

Hi, why you shutdown all VMs and Nodes? corosync and pve-cluster restart can you do while the VMs are still running - without downtime. Udo

Take a look here: https://pve.proxmox.com/wiki/Category:HOWTO There are a section for each version update. And read them carefully! I guess, your disks run some time. Perhaps you should get new ones and install an new version and then import (from backup) your old VMs… If anything don't work...

BTW. the other node can't be have the same output name": "DS-RR", "version": 17, "nodes": 9, "quorate": 0 } the question is, if on all other nodes only ds4-node02 offline? and all have the same version?

you should allways have an backup of your VMs!! Normaly VMs should work after node-update without issues. But it's possible, that you must change something - depends on your setup. Udo

But be aware, that your M-disks in sum are greater then the space on /dev/pve/data - so an extension would be nessessary. And you should update your system! Udo

Hi, if all nodes (except ds4-node06) shows the same, then you can restart cororsync and after that pve-cluster on ds4-node06. And look with "corosync-cfgtool -s" on the nodes. Udo

Hi, your logical volume data: data pve twi-aotzD- 810.75g 100.00 48.49 are full (100%). Because data has 816GB space, but you have vm-disks with 1.37t + 1.5t and so on… You can add another disk to the volumegroup and extend /dev/pve/data - then the VMs...

Hi, how looks "pvecm status" and the content of /etc/pve/.members on the other nodes? Udo

Oh, an historical version of pve! Is there an full filesystem? what is the output of df -h free vgs lvs Udo

Yes, the kernel at this time is the same for no-subscription and enterprise.

I've marked this thread as solved, due 6.2.16-11-bpo11-pve solved the issue. Hope the cherry picking was not forgotten in further kernels. Udo

The day before yesterday, the package was in pvetest only. Download and install: wget http://download.proxmox.com/debian/pve/dists/bullseye/pvetest/binary-amd64/pve-kernel-6.2.16-11-bpo11-pve_6.2.16-11~bpo11%2B2_amd64.deb dpkg -i pve-kernel-6.2.16-11-bpo11-pve_6.2.16-11~bpo11+2_amd64.deb Udo

Du kannst entweder die Disk über die gui detachen und dann erneut hinzufügen. Dann ist es scsi0 (wenn es die einzige disk ist). Dann must Du natürlich die disk auch wieder als boot-device aussuchen. Oder einfach kurz zu Fuß editieren ( vi /etc/pve/qemu-server/103.conf ) - darf halt nur eine Disk...

und die Platte ist auch als scsi0 in der config definiert?!, weil dann hd0,msdos2 und die uuid passen sollte. Hast Du im Grub-Menu noch die Möglichkeit eines anderen systemstart (debug/sicher/usw)?

Hi, gewöhnlich sind die Bottlenecks beim Virtualisieren Ram und IO. CPU kommt erst danach. Hängt natürlich stark vom Anwendungsfall ab. Ich würde es erstmal testen und dann weiter sehen… Apropos IO - da ist die Frage was für SSDs du hast. Gerade bei Consumer-SSDs kann es durchaus langsam...

Same here. Test on an 7.4-Cluster run without trouble with the 6.2.16-11-bpo11-pve. Udo

Hi, but pve-kernel-6.2.16-4-bpo11-pve include the issue, perhaps pve-kernel-6.2.16-11-bpo11-pve_6.2.16-11~bpo11+2_amd64.deb contains the fix for pve7? Or must we wait for pve-kernel-6.2.16-12 on pve7? Udo