<html><head></head><body>Ah. Now I begin to understand what you're after.<br>
<br>
(All commands from memory - check man pages for syntax)<br>
<br>
Create a new disk in PVE. (Suggest creating at as virt-scsi, not virtio, so that you get TRIM support.)<br>
<br>
pvcreate /dev/vdb<br>
vgcreate DATAVG /dev/vdb<br>
lvcreate -l90%VG -n DATALV DATAVG #leave a little emergency expansion room for next time<br>
mkfs.ext4 /dev/DATAVG/DATALV<br>
mount /dev/DATAVG/DATALV /mnt<br>
rsync -vaxHAXES /opt /mnt<br>
# shut down daemons now<br>
rsync -vaxHAXES /opt /mnt #yes, again<br>
umount /opt<br>
mount /dev/DATAVG/DATALV /opt<br>
# start daemons again<br>
vi /etc/fstab # make sure correct partition mounts at boot!<br>
<br>
# optional so you don't remount the old files by accident..<br>
dd if=/dev/zero of=/dev/vda9 bs=512 count=32768<br>
<br>
Later, when you begin to run out again, either add a new disk, pvcreate, vgextend, lvextend, resize2fs, OR just grow it.<br>
When you use an entire raw device as a PV, there's no partition table to worry about editing when you resize. Others will argue that a partition table is an important safety measure - choose which benefit you prefer.<br>
<br>
-Adam<br><br><div class="gmail_quote">On February 3, 2016 4:04:08 AM CST, Gilberto Nunes <gilberto.nunes32@gmail.com> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div dir="ltr"><div><div><div><div><div><div><div><div><div>So, that's the idea...<br /></div>The FS I want grown, is /dev/vda9 that is mounted as /opt.<br /></div>I resize the this via PVE web portal.<br /></div>The /dev/vda had 2 TB and I added more 500 GB...<br /></div>Cfdisk, and parted as well, show that just after /dev/vda9, I have more 500 GB free space....<br /></div>I just want to know, with some certain degree, that I will not loose my data under /opt.... All I need...<br /></div>But, as you said: MAKE BACKUP!<br /></div>The problem is: backup from a 2 TB image, that is use as mail server is very slow and problematic....<br /></div>But I will give a way!<br /></div>Thanks btw!<br /><div><div><div><div><div><br /></div></div></div></div></div></div><div class="gmail_extra"><br /><div class="gmail_quote">2016-02-03 5:07 GMT-02:00 Wolfgang Bumiller <span dir="ltr"><<a href="mailto:w.bumiller@proxmox.com" target="_blank">w.bumiller@proxmox.com</a>></span>:<br
/><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> On February 2, 2016 at 8:07 PM Adam Thompson <<a href="mailto:athompso@athompso.net">athompso@athompso.net</a>> wrote:<br />
><br />
> On 16-02-02 11:24 AM, Gilberto Nunes wrote:<br />
> > Hi<br />
> ><br />
> > And what if I work with BTRFS inside the VM???<br />
> > The FS where VM image lay could be any other FS... Currently, I am use<br />
> > GlusterFS + XFS.<br />
> > I need LVM or BRTFS inside the VM, in order to resize disk partition...<br />
> > And I am between LVM or BRTFS....<br />
><br />
> Only if you need to do *online* resizes (without unmounting the<br />
> filesystem). If you can live with unmounting the filesystem, plain old<br />
> ext3 (and ext4) can do what you need. Of course, if it's the root<br />
> filesystem you need to resize, the only way to unmount it is to shut<br />
> down the VM and reboot it in single-user mode. I think you might need<br />
> to boot off a CD to resize the root fs, can't remember if there's a way<br />
> around it.<br />
<br />
</span>Actually resize2fs works on mounted file systems as long as you're only<br />
growing it and not shrinking it, including the root filesystem.<br />
<span class=""><br />
>><<<br />
<br />
> On February 2, 2016 at 4:38 PM Gilberto Nunes <<a href="mailto:gilberto.nunes32@gmail.com">gilberto.nunes32@gmail.com</a>> wrote:<br />
> That's other doubt... I will lose data if I do it with parted resizepart???<br />
<br />
</span>No, but naturally you should make a backup just in case, especially when<br />
you do this the first time.<br />
Of course there are some limitations when you need online resizing without<br />
downtime. Then you can only grow a partition without moving it. In other<br />
words you can only resize a partition if there's physical free space directly<br />
after it. (Most of the time this is the case since you usually have the<br />
boot partition first and then the root and maybe a home or data partition,<br />
and most of the time that last one is the one you want to resize ;-) )<br />
Eg. with [boot, root, home] after resizing the physical disk you end up with<br />
[boot, root, home, <frees space>], so you can only resize the home partition.<br />
If you can afford down time you can also use parted to move partitions so that<br />
you can resize any of them. This however takes a lot longer and is a bit<br />
more risky, so in this case you should _always_ make a backup even if you know<br />
what you're doing.<br />
<br />
</blockquote></div><br /><br clear="all" /></div></blockquote></div><br>
-- <br>
Sent from my Android device with K-9 Mail. Please excuse my brevity.</body></html>