Search results

please also provide those (from a failing migration of course ;))

well, that upgrade likely changed other parts as well. it seems very likely that it's the change in kernel version that is at fault, but it would still be great to confirm!

das ist aus der ferne etwas schwierig.. https://pve.proxmox.com/wiki/Recover_From_Grub_Failure versucht das ganze zu erklaeren, aber wenn du gar nicht weisst wie die dinge zusammenhaengen kann das durchaus auch in die hose gehen wenn das falsche kommando ausgefuehrt wird..

that sounds like a different issue with similar symptoms. check the start log of the VM on the target node, and the system log of the target node - likely you will find an error about the VM crashing tehere..

if the VM crashes during the migration, then there is no state anymore so yes, the next start of the VM is fresh and should be good. but I would recommend not live migrating in that case, but shutting the VM down before migration.

die boot order laesst sich normalerweise im BIOS einstellen.. seltsam das UEFI nicht geht, aber legacy boot scheinbar schon. um das zu reparieren, musst du vermutlich von einer live cd im UEFI modus booten, die PBS installation mittels chroot "betreten" und den bootloader neu aufsetzen..

we will likely revert to just using RSS, see the discussion on list. I will update the bug report once a new version of the patch is available.

if you reboot your PBS system, you'll see a new tmpfs mount point for /run/proxmox-backup that has no inode limit. you have a rather big datastore, so yes, a lot of lockfiles for S3 are expected. the good thing is they take up barely any resources (other than inodes) because they are stored on...

that likely means that your storage doesn't offer efficient discards. this is a hard problem to solve, as the 60s are a cluster-wide hard-coded limit, so it's not easy to change. and also blocking the whole storage w.r.t. operations modifying LVM (allocation, renames, removal of volumes or...

yes, just reboot them to get a new QEMU process

that would require leaking storage internals into the backup config, which we try to avoid. setting up multiple storages works fine, and also allows to hand out different levels of access on the PVE side.

the issue can also manifest itself with crashing a while after the migration, so if you know it's a problematic combination of node + CPU type, I would not recommend live migrating in the first place.

the CPU type cannot be changed while the VM is running.. so you need some amount of downtime anyway, either for offline migration, or for changing the CPU type ;)

could you answer the question? the "bad" fingerprint must come from somewhere..

this just affects the live state of the VM that is migrated in any fashion, - which includes live-migration as well as a hibernation or snapshot with RAM that is saved on one node and resumed/rolled back on another with different CPU type.

related: https://bugzilla.proxmox.com/show_bug.cgi?id=5796

note that live migration between intel and amd are not guaranteed to work, even when using non-physical CPU types: https://pve.proxmox.com/pve-docs/pve-admin-guide.html#_cpu_type

does the "bad" fingerprint match the issuer of your certificate?

backups sind self-contained. aber das problem hoert sich nicht so an als wuerde es eine neuinstallation erfordern ;)

could you try (installing and) booting the 6.14 kernel on the 9.1 machine?