[PVE-User] BTRFS...

[Adam Thompson]

On 16-02-02 11:24 AM, Gilberto Nunes wrote:
> Hi
>
> And what if I work with BTRFS inside the VM???
> The FS where VM image lay could be any other FS... Currently, I am use 
> GlusterFS + XFS.
> I need LVM or BRTFS inside the VM, in order to resize disk partition...
> And I am between LVM or BRTFS....

Only if you need to do *online* resizes (without unmounting the 
filesystem).  If you can live with unmounting the filesystem, plain old 
ext3 (and ext4) can do what you need.  Of course, if it's the root 
filesystem you need to resize, the only way to unmount it is to shut 
down the VM and reboot it in single-user mode.  I think you might need 
to boot off a CD to resize the root fs, can't remember if there's a way 
around it.

But let's say you create your VMs with two vdisks: one for boot+root 
(these don't even have to be separate partitions), one for /home.
To make this a concrete example, let's say Disk 0 (sda) is 10GB and Disk 
1 (sdb) is 10GB.
Ensure the VM has hot-plugging enabled for disk devices.
Let's say /dev/sda1 (/) is ext4 and /dev/sdb1 (/home) is ext4.  No LVM 
and no BTRFS.
/dev/sdb is MBR-partitioned for simplicity.
Make sure no processes at all are using /home.
Unmount /home.
In PVE management UI, resize Disk 1 to (for example) 20GB.
If the Linux kernel doesn't pick up the change immediately, make sure 
you are running acpid, and you may want to run "rescan-scsi-bus.sh 
--remove --forcerescan" (in RPM: sg3_utils, and in DEB: scsitools) 
and/or "sfdisk --re-read /dev/sdb".
Use fdisk/gdisk/parted/whatever to grow the partition.
Now run "resize2fs /dev/sdb1" and it'll grow the filesystem to the new 
disk size.
Finally remount /home and restart any services depending on it.


Instead, if you used LVM, you could just add a new SCSI disk entirely 
(not resize the existing one), then "pvcreate /dev/sdc" + "vgextend 
my-existing-vg-name /dev/sdc" + "lvextend --extents +100%FREE --resizefs 
my-vg-name/mv-lv-name /dev/sdc".  It's definitely 
simpler/easier/less-disruptive.

(You can also resize the PV in LVM, but if zero-downtime is the goal, 
it's much easier to keep adding new SCSI devices and extending the VG+LV.)

Or do you need to *shrink* the disks?  That's a whole different story... 
I don't think PVE can even shrink virtual disks in the first place.  You 
can do the first scenario I described above, except instead, use 
"resize2fs -M /dev/sdb1" to shrink it instead.

If you consistently need to shrink filesystems, I would use ext3 on top 
of LVM; use "resize2fs -M /dev/vg/lv" first, then "lvreduce --size -10G 
/dev/vg/lv" but be REALLY careful with the size you provide to 
lvreduce!  (You can also use lvresize, there isn't much difference.)

Lastly, if you're using QCOW2 for VM disks, that's a whole 'nother level 
you have to worry about if you're trying to shrink disks; if you're 
using virt-scsi, I think you can do an "fstrim /home" first to signal 
that some blocks can be reclaimed, then just compact the QCOW2 file.  
(See https://pve.proxmox.com/wiki/Shrink_Qcow2_Disk_Files for the older 
approach.)  Then you have to take the VM offline, copy the QCOW2 out to 
a smaller, compacted, file, and reboot the VM with that file attached 
instead of the original QCOW2 file.


You'll need to provide *exact* details of what your actual goal is here, 
if nothing I've said so far covers it.

-Adam