Search results

please, click the host mng01, disks. send screenshot.

just to clarify, with "host graph" do you mean ram usage when you select a VM the used mem graph, or when you select the Host its overall mem usage is higher than allocated to VMs as min and max? (later as in OPs screenshots) in case of Host, there are other consumers, other than VMs and CTs...

Thanks and forgive me my ignorance, what is about the time to sync from root namespace to namspace xyz on same datastore? is it comparable to a verify job (slow), or like a garbage collection (fast), or something in between or out of those two comparisons? i am asking, because my root namsepace...

Thank You Fabian, sadly i can test the older pve-qemu-kvm coming weekend at earliest (service time window), since all vms need to be rebooted and i lose dirty map again. If i understand it correctly, todays updates contain a regression patch for the "bdrv_co_block_status" issue, i will try this...

Hello, KRBD doesn't help here, it was already enabled. pve+ceph 13 nodes cluster alls ssd. pbs all ssd. separate 10gbit networks for ceph and public+backup. just now updated and rebooted whole cluster. backups always maxed out the 10gbit network (900MBs for all nodes together), since update last...

1. MacOS does not support Proxmox(Qemu) or any other virtualization, where the host is not a Mac. 2. Big Sur does not support Nvidia GPUs, last support was in Catalina for some selected Nvidia GPUs (IIRC). AMD RX 580x/5800(xt)/6900xt are a good choice, but since Apple is going with own silicon...

this is on roadmap https://pbs.proxmox.com/wiki/index.php/Roadmap

yes, don't just copy&paste the device path. mount ->/dev/sda1 /<- media/RESCUE/boot change that to the actual device path of your ssd with your broken proxmox installation. run "lsblk" to find out which device path you need (and show me the result too) mount /dev/sdyX /media/RESCUE/boot <-...

did you already tried to reinstall grub? update-grub grub-install /dev/sda (your ssd path here)

don't just copy&paste, dev path might be different for you

when you chroot into the volume, your rescue system acts as if pve-root is its own boot volume but running from rescue kernel. so you can issue commands "like" you booted from the offline system (not everything works ofc., but yet it helps).

not only mount pve-root, but chroot into it as described here https://pve.proxmox.com/wiki/Recover_From_Grub_Failure then apt update && apt install proxmox-ve

time zones... i will come back here in 4-5 hours, afternoon at work currently.

if that does not work and pve kernel is also gone, you could mount pve-root again, chroot into it and "apt install proxmox-ve"

i think we only need to fix grub entries then. https://pve.proxmox.com/wiki/Recover_From_Grub_Failure

sounds good so far. missing boot-uuids means actually, that you are booting in legacy mode (grub), not uefi. if i remember correctly, proxmox-boot-tool is for uefi boot. did you eventually changed something in the boot options in bios/eufi?

did you already booted into a rescue disk and had a look into your ssd, if all the data is still there? especially /etc/pve still contains all the configs

i need to know more about your setup. how did you originally installed proxmox? zfs-boot or default lvm? are your vms on a local/local-lvm/local-zfs storage (same disk as OS) or is there a dedicated storage as separate zfs, ceph cluster or something... the more info you can tell, the better we...

Hi, show us your "cleaning" script. i would guess it removed the active pve kernel. you could reinstall it by booting from a debian rescue mode, mount the proxmox disk, add proxmox repositories and install with apt. Your questions: 1. no, if you can't boot into that ssd and use apt. another way...

Totally your own risk (i am not responsible for anything)! Create a fresh backup, before do any resizes! You already shrinked the partition in the vm-disk to 200G so you can "cut" the raw disk the hard way (never shrink disk to exact or smaller size, than your partition!!). zfs set volsize=499G...