Search results

7.0 already contained the relevant commit upstream prior to it being cut: https://git.kernel.org/linus/a664bf3d603dc3bdcf9ae47cc21e0daec706d7a5 (7.0-rc7)

please post the VM configs, full task logs of migration and start tasks as well as the journal from both nodes covering the migration.

that just means you are using Grub directly. what does "pve8to9" now say?

any chance you can switch to UEFI booting? if not, you can still try "proxmox-boot-tool" to install grub onto the ESP, and boot from there. on some systems that works around issues grub might have with larger disks.

that is probably the single case where it can make sense to do this, though in many cases you would also get away with pointing PBS at that distributed storage without S3 as layer in the middle (e.g., cephfs or a block device backed by that storage mounted locally). performance likely won't be...

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

I don't think there is a final decision yet. Currently there are technical blockers that require refactoring of some code for it to be on the table in the first place.. but there's a few considerations that apply here on top of that: - tape works well if you can feed it data, which is at odds...

die zeile die du zitierst ist exakt der befehl/die parameter? ) oder gehts dir darum dass "--storage <backup_storage>" als eigene zeile/prominenter gelogged werden soll, nicht nur als teil des vzdump aufrufs in der ersten zeile? (ich glaub du hast die befehle/logs in der reihenfolge vertauscht...

ja - die usage ist ja auch vom ganzen datastore, nicht von einem einzelnen namespace. die info bzgl. namespace hab ich im originalpost wohl ueberlesen, tut mir leid. DatastoreAudit auf dem datastore selbst erlaubt keinen zugriff auf die backup inhalte (erlaubt aber das auflisten von allen...

no, direct transfers from an S3-backed datastore and tapes are not supported yet.

then please check and post the logs of the two services I mentioned!

a verification of an encrypted snapshot can only verify that each chunk referenced by the indices exists and has a valid CRC. those two checks protect against lost chunks (e.g., because of caching/sync issues, or because other verification tasks already detected those chunks as corrupt and...

the messages indicate that the cluster is not quorate.. did the root partition maybe also run out of space? check the logs of corosync and pve-cluster please!

no, this hasn't been implemented yet.

im log selbst sollte immer alles relevante stehen, aber der task index eintrag hat nur begrenzt platz, daher wird dort der zugehoerige gast nur bei tasks reingeschrieben die nur einen einzelnen gast betreffen. ein task laeuft immer auf einem node, clusterweite tasks gibts also nur im sinne von...

like I wrote earlier - the server will calculate and set the CRC for all incoming chunks, and will verify the digest if the chunk is unencrypted (verifying the digest of an encrypted chunk would require the encryption key, which only the client has)...

das geht mangels strukturiertes task ergebnisse derzeit nur fuer one-off backups *einzelner* gaeste (die haben die VMID in der UPID stehen). die liste wird wirklich nur aus dem index generiert, der hat keine weiteren daten ausser die die in der UPID stehen..

nein, das war nur ein fehler in meinem test setup.. koenntest du die genauen permissions des users/tokens auf PVE seite posten? also fuer den user der in der storage.cfg steht auf PBS seite auf Access Control -> User Management/API Token -> User/Token auswaehlen -> Show Permissions button druecken

kanns reproduzieren! danke fuer den report.

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