Search results

The LCX root volumes are mounted without the ext4 discard flag, so I guess it's not automated. It would be really useful to be able to set the mount options or at least discard. I've put together this small scritp for my test server to aid in a weekly fstrim task. Maybe it helps someone...

Nice. May the --force be with you. (sorry)

Oh well, it's a mess. If you can afford a reboot, disable/unplug HDDs you want to keep and just erase the disks or at least the first few megabytes on them using a rescue cd... Or if you can exactly determine the old HDDs you can do it online and then do a vgscan to refresh the LVM caches and...

You obviously need to specify the UUID of the VG you want to erase. From your post it looks like the UUID is that one. You cannot rename a VG that's in use.

This looks like a zfs volume, do you have snapshots of it, by any chance? Then you can just rollback to a previous state. If you don't have snapshots I suggest trying zfs-auto-snapshots for example. It can save you in many similar situations.

What happens if you try: vgrename 71h4As-Gd2h-MwFn-tjRo-QJHn-qx06-JL4Ag3 pve_old

Any messages? Does /var/local/kuhlerd exist?

You should look into using kpartx.

You can safely do it from initrd: - reboot, and when grub displays the menu, press 'e' on the first line - edit the linux line so it has break=mount at the end and then press ctrl-x - when you get the promt, do 'modprobe zfs' - now do a 'zpool import -d /dev/disk/by-id/ rpool' - verify...

The last import state is cached so basically you don't need to. Other than that I wonder if it could cause any problems...

It has been mentioned multiple times in these forums and overall this is the recommended way. I have no idea why PVE folks still don't follow it. I changed the device naming by stopping server booting at the mount state and did a "zfs import -d /dev/disk/by-id/ poolname" where it was necessary.

They do provide a rescue facility for you, though, including remote kvm + virtual media.

Your logic is just play of words. SLC was first. Technology is irrelevant nowadays, the important is proven reliability, using whatever type of cells. If you read my first post, you'll see I also recommended an enterprise drive.

TLC (Triple Level Cell) is a variant of MLC (Multi Level Cell). That distinction is getting less important as technology advances but in a sense you're righ, since TLC used to refer to 3L cells only.

Both of these are MLC NAND technology. However, the most important distinction is that the Crucial MX300 has internal power loss protection capacitors. That's very important for server usage. Between these two, definitely the Crucial. Or get some Intel DC S3500 drives used if you want to go...

What kind of hardware do you have? I had problems with older servers and in general older motherboards using usb boot. In those cases, I use a usb dvd drive and a dvdrw disk to avoid hours of fruitless struggle. This method always worked. In any case, double-check you're not booting off...

Well, after setting the volsize to the desired new value, you'll need to fix up the size value in your qemu vm convig under /etc/pve/... too. That should do it, but by that time you'll need to have prepared the shrinked fs inside the guest. According to this issue, you might need to...

[Sorry...]

PVE supports increase even on the web GUI and then you can adjust partitions inside the guest. You can decrease manually but that requires more complex preparation.

Yes, you can do that - but always use a (zfs) clone of the zvol before attempting that, or even better for consistent results, shut down the vm and then use directly, clone/restart etc.