resizing the hard disk on OES server - to add new partitions

I have Suse linux 11 SP4 with OES 2015. It is running in virtual machine. We are running out of space so I shutdown the server and increased the hard disk size (virtual hard disk). But after booting the SLES server and checking the hard disk it is not showing the increased size. This used to work before. Also, it is not allowing us to resize the partition that contains the OES data pool. The HD that is hosting the OES Data pool is of type GPT

  • 0  

    Increasing the drive size, does Not increase the partition. Some additional steps in each case.

    I found I had to boot a GParted ISO to do the root partition.  But do make sure you have a full image backup before doing this. 

    get the root partition issues sorted out first. How big is it currently and what are you aiming for?

    for NSS -
     - use iManager (storage role) to grow the pool size first, up to the 2TB limit you have at that version level.  Only once that is done can you grow the volume.  If you are going beyond the 2TB level, say so as we can get a volume as big as 8TB

    for further details, we will need to know which virtualisation you are running.

    ________________________

    Andy of KonecnyConsulting.ca in Toronto
    Please use the "Like" and/or "Verified Answers" as appropriate as that helps us all.

  • 0 in reply to   

    I am using KVM virtualization. My data disk size is 800GB. I increased the size of this to 900GB using qemu-img command. But after rebooting it is not showing the increased size (with unallocated region) So I cannot use iManager to grow the pool. I tried this on another test sever. There the disk type was MSDOS, here it shows the increased size of attached disk as unallocated. Then I can use nssmu to expand the pool.

    Would GParted live help in increasing the size of disk?

    Regards,

  • 0   in reply to 

    I have never used or needed GParted for NSS volumes. I'm just used it for the root partition, since as a general rule, the root partition can not be changed while running the OS is running off of it.

    As for the expansion working for the old MSDOS partitioning, but not for GPT, that sounds more like an issue at the KVM layers.  I don't yet have any KVM experience outside that older meaning of the term of the physical switches.  If no one else here joins in, you might want to look at KVM focused areas.

    Here is where GParted might be useful, just to compare what it sees between the v-drives under both GPT vs your MSDOS test.

    ________________________

    Andy of KonecnyConsulting.ca in Toronto
    Please use the "Like" and/or "Verified Answers" as appropriate as that helps us all.

  • 0   in reply to 

    What is "it" when you say "it is not showing the increased size". Which tool do you use to check the disk size?
    And, please, do not use imanager to manipulate disks. Use nssmu only.

  • 0 in reply to   

    I use yast2 disk (partitioner) to see the hard disks and partitons. One thing I noticed is that in a test server with GPT type hard disk, resizing using qemu-img command shows the increased size, so it does not seem to be problem with GPT type partitions. Is there any limit after which we cannot grow the disk size? Current size is 800GB. I might just add another disk and create another pool/volumes in it.

  • Suggested Answer

    0   in reply to 

    First look at what the hypervisor passes to the virtual machine from the virtual hard disks.

    To do this, query fdisk -x in the CLI with root rights

    Here in the example, an sdb with 100 GB is being judged and then later transferred to the NSS via /dev/mapper/PA. Incidentally, /dev/mapper/PA is written from the nssmu as an attachment to the device sdb1, Nw_PaRtItIoN is the flag for nss netware here. The partitions on the /sda are of no interest, but it can be inferred that a UEFI boot is present

    This is the first approach to be able to make any statement at all. Does the fdisk -x even show the newly allocated space?

    Here also the red marked text for the /sdb. The info shows the start sector and end sector and that the /dev/sbd is completely allocated. In the case described in the initial post, free sectors and blocks should be shown. If this is not the case, a refresh of the partition table must be carried out in the VM. Normally it is sufficient to call yast partition, all partition information is read this way. To do this, “Rescan” can be called up in Yast under System. The current Yast logs (xml or yml) should be in /var/log/YaST2/storage, where you can also find the information about the detected devices



    example

    fdisk -x


    Disk /dev/sdb: 100 GiB, 107374182400 bytes, 209715200 sectors
    Disk model: Virtual disk
    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: 9CB4C2DA-9AD5-BE4A-BBA3-8608B2435C1B
    First LBA: 34
    Last LBA: 209715166
    Alternative LBA: 209715199
    Partition entries LBA: 2
    Allocated partition entries: 128

    Device     Start       End   Sectors Type-UUID                            UUID                                 Name         Attrs
    /dev/sdb1     64 209711999 209711936 505F774E-5261-4974-7449-6F4E30363500 4240A6F0-86AC-9244-9B90-9549F6E019AE Nw_PaRtItIoN


    Disk /dev/sda: 75 GiB, 80530636800 bytes, 157286400 sectors
    Disk model: Virtual disk
    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: dos
    Disk identifier: 0x6f448442

    Device     Boot     Start       End  Sectors Id Type                 Start-C/H/S   End-C/H/S Attrs
    /dev/sda1  *          128   1042559  1042432 83 Linux                      0/2/3   64/228/36    80
    /dev/sda2         1042560   9429119  8386560 82 Linux swap / Solaris   64/228/37  586/238/36
    /dev/sda3         9429120  73398399 63969280 83 Linux                 586/238/37 1023/213/61
    /dev/sda4        73400320 157286399 83886080  f W95 Ext'd (LBA)      1023/254/63 1023/254/63
    /dev/sda5        73402368 146333695 72931328 83 Linux                1023/254/63 1023/254/63
    /dev/sda6       146335744 157286399 10950656 83 Linux                1023/254/63 1023/254/63


    Disk /dev/mapper/PA: 100 GiB, 107372494848 bytes, 209711904 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

    For the interested among us: The system is an OES 24.4.1 and runs under btfrs. The OES documentation advises not to use btrfs when running eDir on a system. The same is also recommended for databases. It is possible to mount /var/opt/novell/eDirectory, e.g. in an xfs partition. Similar configurations are used in the field by customers for Messenger, SMG, Retain, Vibe and other OT products. The unmounting of var and the associated paths in which installations are located as a bind mount offers great flexibility if disk space becomes too small and needs to be expanded.

    Example

    cat /etc/fstab

    UUID=b196ca17-96a4-49f2-b66d-0d9beef0235c  /                       btrfs  defaults                      0  0
    UUID=b196ca17-96a4-49f2-b66d-0d9beef0235c  /var                    btrfs  subvol=/@/var                 0  0
    UUID=b196ca17-96a4-49f2-b66d-0d9beef0235c  /usr/local              btrfs  subvol=/@/usr/local           0  0
    UUID=b196ca17-96a4-49f2-b66d-0d9beef0235c  /tmp                    btrfs  subvol=/@/tmp                 0  0
    UUID=b196ca17-96a4-49f2-b66d-0d9beef0235c  /srv                    btrfs  subvol=/@/srv                 0  0
    UUID=b196ca17-96a4-49f2-b66d-0d9beef0235c  /opt                    btrfs  subvol=/@/opt                 0  0
    UUID=b196ca17-96a4-49f2-b66d-0d9beef0235c  /home                   btrfs  subvol=/@/home                0  0
    UUID=b196ca17-96a4-49f2-b66d-0d9beef0235c  /boot/grub2/x86_64-efi  btrfs  subvol=/@/boot/grub2/x86_64-efi  0  0
    UUID=b196ca17-96a4-49f2-b66d-0d9beef0235c  /boot/grub2/i386-pc     btrfs  subvol=/@/boot/grub2/i386-pc  0  0
    UUID=4dbe8ebd-3472-434d-bdff-fc1a3d7db636  swap                    swap   defaults                      0  0
    UUID=b196ca17-96a4-49f2-b66d-0d9beef0235c  /.snapshots             btrfs  subvol=/@/.snapshots          0  0
    UUID=f1d362d7-f93f-453a-a6aa-f3c063293f83  /var/opt/novell/eDirectory  xfs    defaults                      0  0
    DATEN /media/nss/DATEN nssvol noauto,name=DATEN 0 0

    Greetings George

    “You can't teach a person anything, you can only help them to discover it within themselves.” Galileo Galilei

  • 0   in reply to 

    Sorry for stating the obvious, but the obvious answer is that your hypervisor did *not* extend the disk. or you did not reboot the guest. That's basically the only two serious options.

  • 0 in reply to   

    I rebooted the guest but still partitioner does not show the unallocated space. fdisk does not have -x option in my OS. Also "parted" is showing disk size as 850GB instead of 900GB. Anyhow, I am going to add another disk create another pool and move the volumes from the existing pool. Thanks everyone for your help.