I see your point of view, Wolfgang... But I just bring this matter at light because I see from other perspective: inside the VM. I usually work with KVM guest. Now, occur to specific VM to run out of space in a virtual hard disk. I forgot to use LVM and as consequently, I will need added a new disk and format it as LVM or BTRFS, in order to be able to increase the virtual disk later... Now, the disk is /dev/vdaX format as XFS... I already growed up the image to the necessary additional space, but I am not can increase the volume... I try xfs_growfs but doesn't work... So, I make same research by myself I think about BTRFS or LVM... So, follow your advice, is better to my sanity, continue my life with LVM, at least for now...
2016-02-02 13:20 GMT-02:00 Gilberto Nunes <[email protected]>: > I see your point of view, Wolfgang... > But I just bring this matter at light because I see from other > perspective: inside the VM. > I usually work with KVM guest. > Now, occur to specific VM to run out of space in a virtual hard disk. > I forgot to use LVM and as consequently, I will need added a new disk and > format it as LVM or BTRFS, in order to be able to increase the virtual disk > later... > Now, the disk is /dev/vdaX format as XFS... > I already growed up the image to the necessary additional space, but I am > not can increase the volume... > I try xfs_growfs but doesn't work... > So, I make same research by myself I think about BTRFS or LVM... > So, follow your advice, is better to my sanity, continue my life with LVM, > at least for now... > > > 2016-02-02 12:09 GMT-02:00 Wolfgang Bumiller <[email protected]>: > >> On Tue, Feb 02, 2016 at 11:40:47AM -0200, Gilberto Nunes wrote: >> > Well >> > >> > I almost do it, 'cause one of feature I appreciate in btrfs is the >> hability >> > to increase or decrease disk size. >> > I know LVM can do it as well, but LVM are always on top whatever X >> > Filesystem. >> >> From our perspective it would bring a bunch more useful features to the >> table like snapshots, but for this particular task it's not actually any >> more convenient than running resize2fs on an image or LVM, so we only >> see the "not-yet mature enough" side of the story. At least with our >> current kernel version. >> And we wouldn't get rid of the additional layers since it would still >> have to be used on top of our storage backend management. >> >> As for convenience: eg. for the `pct resize` command if the container is >> offline we just run our backend's resize function (which is still >> required with btrfs to eg increase the image file or zvol or lvm >> portion) and then run resize2fs on it. With btrfs we'd also have to >> mount it for such operations because they only work on mountpoint-paths. >> Although for a running container this isn't actually a problem as you >> *can* pass a path like /proc/${ContainerPID}/root/ which I find almost >> surprising since some other commands like 'mount' often do something >> unexpectedly *bad* with paths like that. >> >> > So do you have more layers... Btrfs is direct into the device. Or am I >> > wrong?! >> > >> > >> > 2016-02-02 11:30 GMT-02:00 Paul Gray <[email protected]>: >> > >> > > On 02/02/2016 07:11 AM, Gilberto Nunes wrote: >> > > > And more important: any one here already use or test BTRFS inside >> > > > Proxmox? With qcow2 or raw images??? >> > > >> > > I'm using btrfs for a trial vm image storage, but not yet at a point >> > > where I could make a recommendation for or against it either way. >> > > >> > > -Paul >> >> > > > -- > > Gilberto Ferreira > +55 (47) 9676-7530 > Skype: gilberto.nunes36 > > -- Gilberto Ferreira +55 (47) 9676-7530 Skype: gilberto.nunes36
_______________________________________________ pve-user mailing list [email protected] http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-user
