Search results

The usual boot process uses the BIOS firmware to read the very first blocks of the operating system. This is before even the "initrd"/"initramfs" is available = "pre-boot". While boot devices may be local hardware and network devices with some different flavors of well established network-boot...

I would expect this behavior. And yes, the ARC only gets actually used when ZFS recognizes relevant read pattern by watching the MRU/MFU counters. (--> "warm up". Newer systems may reload the ARC on boot from disk though...)

Es gibt natürlich zahlreiche valide Ansätze. Ich verwende (im Homelab) "Zamba": https://github.com/bashclub/zamba-lxc-toolbox. Damit bekommt man einen ausgereiften AD-kompatiblen Fileserver, der für die Windows-Nutzer beispielsweise die regelmäßig erstellten Snapshots via "Vorherige...

Yes, that's the culprit. I've been there once. The lesson I learned was to only modify the structure of a cluster when all nodes are online :-) The workaround is to make corosync.conf editable. As that node has not quorum you need to mount the configuration database locally and edit the file...

Just restore the VM of your choice on the other node. The storage type on the other node does not have to be the same as it was on the source. The result is basically a "replicated" VM from/to different filesystems ;-) The are CLI tools available, so you can script the whole process to...

Hinsichtlich live-Migration, ja. Richtig, der ist ja gerade kaputtgegangen. Naja, wie in #2 schon erwähnt: du verlierst die Daten seit der letzten Replikation. Aber ja, auf dem überlebenden Node startet HA diese VM neu. Automatisch!

There are so many modifications in changed subsystems from Debian Buster --> Bullseye --> Bookworm --> Trixie. While I do have some systems (not PVE) which were upgraded from Stretch to now I would choose to create a new install and restore VMs from backup. This seems easier to me - and then...

To separate "the OS" from "the data" is still best practice, yes! For PVE the OS should reside on a mirror, of course. With the constraints of "Mini-PCs" I feel fine to just install PVE on two (or more) devices, in a ZFS mirror. The resulting single ZFS pool ("rpool") is good to use for all...

Yes, technically everything is possible as "everthing is a file". You can stack filesystems on top of block devices as usual and then repeat this step as often as you want to. (Or an LVM physical volume on top of a ZVOL.) The complexity multiplies on each step. And so does the difficulty to...

Unfortunately I have no NFS storage configured, so I can't confirm this. But my only "cifs" share does confirm your observation: no explicit "shared 1" but it is shared.

For VM disks to not being copied the underlying storage needs to be officially tagged "shared". Compare your settings with the table: https://pve.proxmox.com/pve-docs/pve-admin-guide.html#_storage_types And it needs to be actually configured accordingly. Just having "the same" storage on two...

No. But from my perspective it is expected behavior to copy the data from one single machine to another single machine. The alternative is (of course) to build a cluster. Only then the relevant software knows, what "shared storage" means...

What do you mean by "resource intensiv"? CPU load? Slow transfer speed? Not many IOPS? Power consumption? For HDD the limiting factor is always the mechanical behavior of the disks, never the CPU. At least not for the last few decades. If I am offered RaidZ1 plus spare I would always opt for...

Tja, ein klassisches "Catch-22" ;-) Erstens: mach ein Backup vor allen Experimenten! Die "richtige" Lösung könnte der POM sein, der ist explizit für offline-Szenarien gedacht: https://pom.proxmox.com/ "Basteln" kann man mit "apt -d -y full-upgrade", nach dem Umschreiben der sources.list...

Ich mache mal den Erbsenzähler: die Formulierung ist so nicht richtig. Die VM wird nicht erneut komplett gesichert! Aber sie wird auf der Quelle jeweils erneut komplett eingelesen, "gechunked", die Checksumme ermittelt, diese zum PBS gesendet und danach wird erst erkannt, dass dieser Chunk...

A ZFS pools consists of one or more vdevs. Vdevs implement the known topologies: single drive/mirror/RaidZx. When you have more than one vdev the combination in a pool is called "striped". (Nearly) every ZFS pool I have has more than one vdev --> the pool is striped. IOPS scale linear with the...

Well, you can put different sized disks into one pool. "Striped". This is NOT recommended because it removes some very important features! A mirror (and that's what we mostly use in PVE context) needs two (or more) same sized disks. You can force it to use different sizes like your 18+10...

No - the result you've shown is exactly this: two mirrors, striped :-) No, that's not possible. You will have to create a new pool with a single mirror first. (Well, technically a single drive is enough - you can add a second drive to create the first mirror later on. This approach is not...

Sorry, I do not know that. My normal Desktop works with Spice+"VirGL GPU" - and that was your initial question in #1 ;-)

Just for clarity, while the result may look the same, PVE HA is the opposite: not "shoot-the-other-node and live" but "commit suicide" - a node fences itself, by a hard reset.