OMV in VM - how to resize data disk?

1. offizieller Beitrag

    Hi


    I have OVM in VM, two virtual disks, 20gb for system, 50gb for user's data ext4. I runned out of space on data disk. I've expanded vdisk from 50 to 100GB in hypervizor and resized data partition offline using gparted live (because any resize option was not available in omv - grayed out) I've started OMV - a mess come in. The expanded disk is now added as separate ~100GB disk, and system alerts about missing 50GB data disk. Fortunately is was only a lab because I'm planning to implement OVM in production and doing some simple manual test.


    My question is how to resize virtual disk that already have a data, shares ect. ? From my perspective it should be simple - I expand the vdisk in hypervizor, then I expand the partition to maximum space available on disk. Or there is a simple way to accomplish this simple task? If now - what? Add another bigger disk and manually copy data over two disks??




    • Offizieller Beitrag

    One possibility is that the UUID/PUUID for the partition/disk changed when you resized. Worth checking.


    If that is case, as far as OMV is concerned you removed a HDD and replaced it with a completely different HDD with a different size.


    Work around is either to edit OMV configuration files and change UUID there or to remove the data HDD from the OMV GUI before you resize and add again, with the new UUID, after.

    When I did this sort of thing on bare metal, I used "parted" to "resizepart" and I'm pretty sure that the UUID was retained by the resized partition. Try that instead of gparted and see what you get.


    Also, since you're using VMs, maybe copy the VM before trying this out, so if it makes a hash of things, you can delete the hashed job and try again.

    As I said - that's a lab - so please tell me, especially maybe donh - because clearly he is smartass - how to properly resize vdisk for data in OMV? talk to me like to child, step by step, I'm newibie with omv.

    Right, so delete the VM where you made a hash of it and use the copy from before you made the to expanded the disk from 50GB to 100GB.


    login as root or sudo to root. You haven't said which drive name is your second drive, so I'm going to call it "/dev/b88b" but you'll need to change that to whichever drive is your 50GB drive. To figure that out, you can use "lsblk"



    And you can follow along with the rest of the "(5) resize a partition" at Tecmint.

    Right, so delete the VM where you made a hash of it and use the copy from before you made the decision to expanded the disk from 50GB to 100GB.


    login as root or sudo to root. You haven't said which drive name is your second drive, so I'm going to call it "/dev/b88b" but you'll need to change that to whichever drive is your 50GB drive. To figure that out, you can use "lsblk"
    next, unmount the drive


    Code
    # umount /dev/b88b


    If that doesn't work it's because the drive is in use. I have no idea what you're using the drive for or how, so I'm not even going to try to enumerate the zillions of ways that might need to be done. Start with making sure it's not used by any of the services or docker and then remove it from the shared folders list. Beyond that you're on your own.


    And you can follow along with the rest of the "(5) resize a partition" at Tecmint.


    After you've resized the disk, I assume you'll want to resize the file system to the full extent of the drive partition.


    Code
    # e2fsck -f /dev/b88b1
# resize2fs /dev/b88b1
# e2fsck -f /dev/b88b1

    should the resize operation be done offline? start some live cd? if not what to do in OMV before extending the disk?
    about the disks in my setup:


    /dev/sda - for omv
    /dev/sdb - for data - and I want to extend this disk.


    I have intermediate linux knowledge ;) but I'm totally new to OMV

    I've exnanded vdisk in virtualbox, then boot of linux mint and ran resize2fs:


    can this operation be done without any errors? I'm the only one who wants to resize data disk in ovm running in virtual machine?



    ---
    On omv box I've stopped all sevices expect ssh to perrform resize2fs:


    /dev/sda1 on / type ext4 (rw,relatime,errors=remount-ro,data=ordered)
    /dev/sdb1 on /srv/dev-disk-by-label-50giga type ext4 (rw,noexec,relatime,data=ordered,jqfmt=vfsv0,usrjquota=aquota.user,grpjquota=aquota.group) [50giga]
    /dev/sdb1 on /sharedfolders/instalki type ext4 (rw,noexec,relatime,data=ordered,jqfmt=vfsv0,usrjquota=aquota.user,grpjquota=aquota.group) [50giga]


    root@omv01:~# resize2fs /dev/sdb1
    resize2fs 1.44.4 (18-Aug-2018)
    The filesystem is already 13106939 (4k) blocks long. Nothing to do!


    I'm using ext as sdb disk - according https://support.citrix.com/art…rix.com/article/CTX125405



    #umount /dev/xvdc1
    #fdisk /dev/xvdc1
    #d (Delete the partition and recreate it)
    #n (New partition)
    #w (Write out table)
    #e2fsck -f /dev/xvdc1
    #resize2fs /dev/xvdc1
    #mount /dev/xvdc1 /home


    That should do, but there is abovementioned error:


    root@omv01:~# resize2fs /dev/sdb1
    resize2fs 1.44.4 (18-Aug-2018)
    The filesystem is already 13106939 (4k) blocks long. Nothing to do!


    ---
    2nd try directly on omv:
    root@omv01:~# resize2fs /dev/sdb1
    resize2fs 1.44.4 (18-Aug-2018)
    Please run 'e2fsck -f /dev/sdb1' first.


    root@omv01:~# e2fsck -f /dev/sdb1
    e2fsck 1.44.4 (18-Aug-2018)
    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
    50giga: 31/3276800 files (3.2% non-contiguous), 447144/13106939 blocks
    root@omv01:~# resize2fs /dev/sdb1
    resize2fs 1.44.4 (18-Aug-2018)
    The filesystem is already 13106939 (4k) blocks long. Nothing to do!


    ---
    IDK - maybe it's some virtualbox quirk? Can anyone make simple vlab with omv - two disk, 20 system, 50gb data, then expand second disk to 100gb, and then try to expand disk so OMV could use whole 100gb space?



    ----


    if you follow the parted instructions I provided, you would not lose the UUID for the partition when you delete it in fdisk. Sorry if I didn't make it clear why you shouldn't use fdisk for this task.


    # umount /dev/xvdc1
    # e2fsck -f /dev/xvdc1 << the current version in OMV4 is 1.44.4 (18-Aug-2018). Your mint version is from 2015.
    # df /dev/xvdc1
    # fdisk -l /dev/xvdc
    << verify that df reports the xvdc1 size as 50GB and fdisk reports the 100GB size - noting that df reports 1024b blocks and fdisk reports 512b sectors>>
    # resize2fs /dev/xvdc1
    # df /dev/xdc1


    This is pretty reliable.


    The gui can be unreliable if you're doing things at the command line. You'll have cached data on your browser and the nginx engine may potentiall cache some data as well.


    I'm not familiar with mint. I use knoppix for a boot OS and it's been completely reliable for me.

    My mint was downloaded three days ago - maybe the iso have old version of software. No no I didnt used fdisk for resize - I know fdisk dont work with gpt disks. I've used parted and also tried resize2fs exacly how I showed here:


    The mint I've used is lmde - its clear debian + some gui stuff

    please refer back to my last post and include the df and fdisk -l info. It looks like the issue is with the drive and partition sizes, not with the resize.


    It's weird that you used "parted", but that somehow translated to "fdisk" when you copied the output here.

    I've just loggen in :)


    this is the data:



    As I suspected, your disk is 100GiB but your partition is still 50GB:

    Code
    GPT PMBR size mismatch (104857599 != 209715199) will be corrected by w(rite).
Disk /dev/sdb: 100 GiB, 107374182400 bytes, 209715200 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
Disklabel type: gpt
Disk identifier: 39D43581-36CA-42A2-B921-3BCE200E8619
Device     Start       End   Sectors Size Type
/dev/sdb1   2048 104857566 104855519  50G Linux filesystem


    Refer back to my post #6. Use Parted to resize /dev/sdb1. Once you've followed that, return here and repost the "fdisk -l" result.


    you want your new

    Code
    resizepart end=209715200S

    Because that's where fdisk reports the disk ends.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden