Search results

the wiki page I was referring to is the one in @grin 's reply right above mine ;) yes, if `pct suspend` (and `pct resume`!) ever work reliably across a range of container loads, implementing "live" migration on top of that would maybe be feasible.

no, that is a clear indicator for hardware errors. yes, a smart long test might be a good idea. or simply reading the disk form end to end and checking if the counter goes up..

unter der annahme dass du aktuelle updates installiert hast, sind das wahrscheinlich false positives. fuer Debian kannst du die CVEs z.B. hier durchgehen: https://security-tracker.debian.org/tracker/source-package/openssl beim kernel musst du aufpassen - der PVE kernel basiert auf Ubuntu's...

probably it was missed because its timestamp was almost a month before it got delivered, so it likely sorted quite far back for most recipients ;) I'll take a look..

Media and Data Integrity Errors: 450 that is not good and possibly the source of your issues.. you might want to run some more in-deph tests and consider RMAing it if it's still covered..

Proxmox doesn't use libvirt, and neither do I - please check the libvirt docs ;)

check the postfix documentation ;)

that is a totally different error: cp: error reading '/usr/lib/x86_64-linux-gnu/proxmox-backup/file-restore/initramfs.img': Input/output error this file should exist on disk and be readable, if it is not, it sounds like your disk might have an issue..

tar: ./var/spool/postfix/dev/urandom: Cannot mknod: Operation not permitted tar: ./var/spool/postfix/dev/random: Cannot mknod: Operation not permitted these two files are special (device nodes), which doesn't work in unprivileged mode. postfix only needs them in certain configurations, so it...

you can try removing those two device nodes prior to making a backup - it might require some changes to the postfix config though..

checksum fehler auf beiden disks ist eher ungewoehnlich, wuerde zur sicherheit auch den RAM und die kabel durchchecken..

koennte ein hinweis auf ein disk problem auf PVE seite sein.. was fuer einen storage verwendest du dort denn?

if you enable the "agent" option on the VM, then PVE will automatically generate a serial device for the agent: -chardev 'socket,path=/var/run/qemu-server/<VMID>.qga,server=on,wait=off,id=qga0' \ -device 'virtio-serial,id=qga0,bus=pci.0,addr=0x8' \ -device...

https://forum.proxmox.com/threads/pmg-hourly-service-ldap-syncronization-not-works.155656/ duplicate thread

sollte jetzt bzw in kuerze gehen!

hab mal nen patch/RFC geschickt: https://lore.proxmox.com/pbs-devel/20241008083355.181031-2-f.gruenbichler@proxmox.com/T/

rein interesse halber - welche distro in welcher version (bzw mit welcher systemd version) habt ihr in den containern laufen?

perfekt, danke!

https://git.proxmox.com/?p=pxar.git;a=summary da gibts ein beispiel binary mit dem sich das eventuell auslesen lest $ git clone .. $ cd pxar # apt build-dep . $ cargo build --release --examples .. $ ./target/release/examples/pxarcmd ls /tmp/foobar.pxar /test Metadata { stat: Stat { mode...

weder file restore noch fuse mount unterstuetzen derzeit ACLs ;) mit der catalog shell sollte ein selective restore aber moeglich sein (oder vielleicht mehr details liefern). ist der ZFS storage noch der gleiche wie der auf dem der container urspruenglich lag? ZFS unterstuetzt naemlich...