Hi everyone.
I noticed this message in the PVE host kernel.
The host is an old Dell server with a PERC/6i and 2 RAIDs: one RAID1 of SSDs and one RAID5 of HDDs.
PVE is installed with the standard LVM thin configuration.
I have enabled discard as I usually do on a Linux guest, and got this...
On is the default config, so setting it to on makes no difference. Off seems to work for quite a lot of old hardware with newer kernels. Set it to off.
Yes, I can confirm the issue is still there (and will never go away, it's an issue with older hardware) and that if you add the intel_iommu=off during installation, then the installer adds it to the installed GRUB so no need to re-add it.
Yes, I understand this is the idea, and I have configured one like this already (one raid5 virtual disk and a single physical disk) in a different scenario. What I don't really know is if this is fine or has issues with ZFS.
Thanks, I definitely don't want to lose ZFS features by using it over a raid setup. If the controller can be completely bypassed by setting it properly and not flashing it, then it would be fine. Even better if I can actually have a hardware raid 1 for the OS and then a ZFS raidz-1 for data...
In our scenario vmware would be using local storage for boot and data, like PVE would. The difference is that Vmware needs a raid controller (an approved one, too), while PVE needs mostly anything that is non-raid to work. The idea here is to buy hardware that we can run with both software...
I've been asked to consider buying a new Dell server that can work both with PVE and Vmware. Vmware requires a compatible raid controller, PVE requires NO raid controller (I want to use ZFS so I can make a ZFS replica to another identical server).
I know that modern PERC controllers can be set...
Thanks a lot. I have read quite a lot of your website articles and while I'm not a Blockbridge customer and I'll probably never be (much smaller setup here) I have appreciated your KB articles a lot.
But now a question has arisen: Is LVM-Thin dangerous as QCOW2 is? I mean, does it also never...
Of course I have offline backups, a management network that's not the same as the users network, restricted access (you need a vpn to access the management from the LAN), etc.
Still I'm thinking of the issues if someone somehow becomes root on the PVE hosts.
As of today I see two scenarios...
Thanks a lot for the explanation, it's very clear and I like the fact that this protects the best part of the backup chain of hardware and software. This means that if the PVE host does not corrupt data, then any further corruption, even in the moment the backup is written to PBS for the first...
I'm looking for an information I cannot find. When a backup is made to PBS, I understand that all the blocks have an hash that allows for integrity checks to be done later, and they indeed are done on the PBS host multiple times. (there is a schedule for that)
But the part I miss is this: is...
Setting an alert on the PBS side is indeed a good idea. If the threat actor has compromised the PVE server (the host, I mean) but for some reason not the PBS server, then we can get an alert for this anomaly in the backup chain.
While I'm sure that a good attack is IMPOSSIBLE to stop, let's at...