[pve-devel] Bug? Resize is not possible

[Wolfgang Bumiller]

On Tue, Sep 01, 2015 at 11:45:11AM +0200, Detlef Bracker wrote:
> Dear,
> 
> I can doe what I will, the /vdb1 in qcow2 OR now in raw-Format has 61,4 GB
> They use 512 Byte Blocks:
> 
> root at localhost:~# fdisk -l
> 
(...)
> 
> Disk /dev/vdb: 64.4 GB, 64424509440 bytes
> 4 heads, 32 sectors/track, 983040 cylinders, total 125829120 sectors
> Units = sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disk identifier: 0x000c3fb3

I don't see a partition list for vdb here, only vda above. Is that all
you get from `fdisk -l /dev/vdb`? If so, what kind of partition table is
used on vdb?

> root at localhost:~# e2fsck -f /dev/vdb1
> e2fsck 1.42.5 (29-Jul-2012)
> Pass 1: Checking inodes, blocks, and sizes
> Pass 2: Checking directory structure
> Pass 3: Checking directory connectivity
> Pass 4: Checking reference counts
> Pass 5: Checking group summary information
> root: 31286/983040 files (0.1% non-contiguous), 277080/3932160 blocks
> root at localhost:~# resize2fs /dev/vdb1 60G

Note that you can leave out the size argument completely if you want to
make it use the entire partition.

> resize2fs 1.42.5 (29-Jul-2012)
> The containing partition (or device) is only 5242624 (4k) blocks.
> You requested a new size of 15728640 blocks.

So the partition isn't big enough. Maybe you only resized the disk but
not the partition table of vdb. As mentioned above, your output only
includes the partition table of vda.

Did you resize the disk while the machine is running? If that's the case
make sure to send a `block_resize` qemu-monitor command, otherwise the
running VM won't see the change in size. (You can use the vm's 'Monitor'
tab in the GUI.)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.proxmox.com/pipermail/pve-devel/attachments/20150901/f4fbd2be/attachment.sig>