Score:0

Ubuntu

moving KVM image from one server to another and then resize

David

5/13/23, 6:50 AM

host1 has a 40G guest image inside an LV.

host2 has a 50G guest LV partition available.

dd to transfer host1/guest(40G) --> host2/guest(50G).

gdisk to correct the location of the GPT table -

root@ns:~# gdisk /dev/vda2
Command (? for help): w
Warning! Secondary header is placed too early on the disk! Do you want to
correct this problem? (Y/N): Y
Have moved second header and partition table to correct location.

reconfigured guest.xml and the guest booted perfectly.

guest has a normal partition - no LV

PROBLEM: I can't resize the filesystem on the guest to fill the entire 50G LV. The guest filesystem remains at 40G.

Disk /dev/vda: 50 GiB, 53687091200 bytes, 104857600 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: 564A38FB-02AE-4E84-B080-173963955B2E

Device     Start      End  Sectors Size Type
/dev/vda1   2048     4095     2048   1M BIOS boot
/dev/vda2   4096 85977087 85972992  41G Linux filesystem

attempt to resize guest:

root@ns:~# resize2fs /dev/vda2
resize2fs 1.45.5 (07-Jan-2020)
The filesystem is already 10746624 (4k) blocks long.  Nothing to do!

This is the output of fdisk -l from the new host:

Disk /dev/mapper/vg--main-nstest: 50 GiB, 53687091200 bytes, 104857600 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: 564A38FB-02AE-4E84-B080-173963955B2E

Device                            Start      End  Sectors Size Type
/dev/mapper/vg--main-nstest-part1  2048     4095     2048   1M BIOS boot
/dev/mapper/vg--main-nstest-part2  4096 85977087 85972992  41G Linux filesystem

.. and this is what happens if I try to resize from the host:

root@virtual3:~# resize2fs /dev/mapper/vg--main-nstest-part2
resize2fs 1.45.5 (07-Jan-2020)
open: No such file or directory while opening /dev/mapper/vg--main-nstest-part2

or.... unsurprisingly:

root@virtual3:~# resize2fs /dev/vg-main/nstest 
resize2fs 1.45.5 (07-Jan-2020)
resize2fs: Bad magic number in super-block while trying to open /dev/vg-main/nstest
Couldn't find valid filesystem superblock.

I tried mounting the guest root partition on the host thus:

# mount  -o loop,offset=2097152 /dev/vg-main/ns-test /mnt

... and then tried to resize the resulting loop device: /dev/loop7 This is a bad idea - it destroys the superblock and the guest won't boot. Back to the drawing board.

0 + 0

partitioning

resize

kvm

disk-image

Score:0

Ubuntu

David

5/15/23, 7:20 AM

Answering my own question. Would love some comments though as some of it seems arcane.

It turns out to be far more complicated than I thought.. here are the notes I made - they include lots of output that might be particular to my situation. Also anything starting with "<<<<" is a comment! Don't copy it!:

PROBLEM: Copied old server qemu image 40G LV to new 50G LV Need to resize the filesystem to 50G

root@virtual3:~# ssh oldserver "dd bs=1M if=/dev/oldvg/oldnstest" | \
           dd status=progress of=/dev/vg-main/nstest
root@virtual3:~# scp oldserver:/etc/libvirt/quemu/oldnstest.xml /etc/libvirt/qemu/nstest.xml
.... edit nstest.xml as required and virsh define nstest.xml

I found some missing bits and errors, but heavily based on this page:

https://subscription.packtpub.com/book/virtualization-and-cloud/9781788294676/1/ch01lvl1sec14/resizing-an-image

  root@virtual3:~# qemu-img info /dev/vg-main/nstest 
    image: /dev/vg-main/nstest
    file format: raw
    virtual size: 50 GiB (53687091200 bytes)
    disk size: 0 B
  root@virtual3:~# losetup -f
    /dev/loop0
  root@virtual3:~# losetup /dev/loop0 /dev/vg-main/nstest 
  root@virtual3:~# kpartx -av /dev/loop0
    GPT:Primary header thinks Alt. header is not at the end of the disk.
    GPT:Alternate GPT header not at the end of the disk.
    GPT: Use GNU Parted to correct GPT errors.
    add map loop0p1 (253:3): 0 2048 linear 7:0 2048
    add map loop0p2 (253:4): 0 85972992 linear 7:0 4096
  root@virtual3:~# parted /dev/vg-main/nstest print
    Warning: Not all of the space available to /dev/dm-2 appears to be used, you can
    fix the GPT to use all of the space (an extra 18877064 blocks) or continue with
    the current setting? 
    Fix/Ignore? fix                                                           
    Model: Linux device-mapper (linear) (dm)
    Disk /dev/dm-2: 53.7GB
    Sector size (logical/physical): 512B/512B
    Partition Table: gpt
    Disk Flags: 
    
    Number  Start   End     Size    File system  Name  Flags
     1      1049kB  2097kB  1049kB                     bios_grub
     2      2097kB  44.0GB  44.0GB  ext4

THE VM STILL STARTS UP - lets see how we go from here!

Note, journaling apparently has to be turned off for this to work, but e2fsck will turn it back on. See below.

  root@virtual3:~# kpartx -av /dev/loop0
    add map loop0p1 (253:3): 0 2048 linear 7:0 2048
    add map loop0p2 (253:4): 0 85972992 linear 7:0 4096
  root@virtual3:~# ls -la /dev/mapper/loop0*
    lrwxrwxrwx 1 root root 7 Jan 13 23:47 /dev/mapper/loop0p1 -> ../dm-3
    lrwxrwxrwx 1 root root 7 Jan 13 23:47 /dev/mapper/loop0p2 -> ../dm-4
    root@virtual3:~# tune2fs -l /dev/mapper/loop0p2
      .... lots of stuff, snipped for brevity
    Filesystem features:      has_journal ext_attr resize_inode dir_index .... etc etc
     .... lots more stuff.... but note "has_journal" above
  root@virtual3:~# e2fsck /dev/mapper/loop0p2   >>>>>>>>fix minor probs?
    e2fsck 1.45.5 (07-Jan-2020)
    /dev/mapper/loop0p2: recovering journal
    Clearing orphaned inode 788499 (uid=0, gid=0, mode=0100644, size=113)
    Clearing orphaned inode 531614 (uid=0, gid=0, mode=0100666, size=0)
    Clearing orphaned inode 531613 (uid=112, gid=117, mode=0100600, size=0)
    Clearing orphaned inode 531610 (uid=112, gid=117, mode=0100600, size=0)
    Clearing orphaned inode 531609 (uid=112, gid=117, mode=0100600, size=0)
    Clearing orphaned inode 531606 (uid=112, gid=117, mode=0100600, size=0)
    Setting free inodes count to 2511295 (was 2511334)
    Setting free blocks count to 6187161 (was 6192365)
    /dev/mapper/loop0p2: clean, 175681/2686976 files, 4559463/10746624 blocks
  root@virtual3:~# tune2fs -O ^has_journal /dev/mapper/loop0p2   >>>> NB: cap O
   tune2fs 1.45.5 (07-Jan-2020)
  root@virtual3:~# tune2fs -l /dev/mapper/loop0p2 | grep "features"
   Filesystem features:      ext_attr resize_inode dir_index  .... etc etc
  root@virtual3:~# kpartx -dv /dev/loop0
   del devmap : loop0p2
   del devmap : loop0p1
  root@virtual3:~# losetup -d /dev/loop0
  root@virtual3:~# modprobe nbd max_parts=8    <<<<< needed to create /dev/nbd*
    (edit /etc/modprobe ... add nbd to make permanent)
  root@virtual3:~# qemu-nbd --format=raw --connect=/dev/nbd0 /dev/vg-main/nstest 
  root@virtual3:~# fdisk /dev/nbd0
    
    Welcome to fdisk (util-linux 2.34).
    Changes will remain in memory only, until you decide to write them.
    Be careful before using the write command.
    
    
    Command (m for help): p
    Disk /dev/nbd0: 50 GiB, 53687091200 bytes, 104857600 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: 564A38FB-02AE-4E84-B080-173963955B2E
    
    Device      Start      End  Sectors Size Type
    /dev/nbd0p1  2048     4095     2048   1M BIOS boot
    /dev/nbd0p2  4096 85977087 85972992  41G Linux filesystem
    
    Command (m for help): d
    Partition number (1,2, default 2): 2
    
    Partition 2 has been deleted.
    
    Command (m for help): n
    Partition number (2-128, default 2): 2
    First sector (4096-104857566, default 4096): 
    Last sector, +/-sectors or +/-size{K,M,G,T,P} (4096-104857566, default 104857566): 
    
    Created a new partition 2 of type 'Linux filesystem' and of size 50 GiB.
    Partition #2 contains a ext4 signature.
    
    Do you want to remove the signature? [Y]es/[N]o: n      <<<< NB!
    
    Command (m for help): w
    
    The partition table has been altered.
    Calling ioctl() to re-read partition table.
    Syncing disks.
    
  root@virtual3:~# qemu-nbd --disconnect /dev/nbd0   <<< this step not on webpage
    /dev/nbd0 disconnected
  root@virtual3:~# e2fsck -f /dev/mapper/loop0p2
    e2fsck 1.45.5 (07-Jan-2020)
    Superblock has an invalid journal (inode 8).
    Clear<y>? yes
    *** journal has been deleted ***
    
    Clearing orphaned inode 788499 (uid=0, gid=0, mode=0100644, size=113)
    Illegal inode 1642119663 in orphaned inode list.
    Pass 1: Checking inodes, blocks, and sizes
    Deleted inode 531606 has zero dtime.  Fix<y>? yes
    Inodes that were part of a corrupted orphan linked list found.  Fix<y>? yes
    Inode 531609 was part of the orphaned inode list.  FIXED.
    Inode 531610 was part of the orphaned inode list.  FIXED.
    Inode 531613 was part of the orphaned inode list.  FIXED.
    Inode 531614 was part of the orphaned inode list.  FIXED.
    Pass 2: Checking directory structure
    Pass 3: Checking directory connectivity
    Pass 4: Checking reference counts
    Pass 5: Checking group summary information
    Free blocks count wrong for group #97 (21582, counted=21583).
    Fix<y>? yes
    Free blocks count wrong (6192364, counted=6252696).
    Fix<y>? yes
    Inode bitmap differences:  -531606 -(531609--531610) -(531613--531614) -788499
    Fix<y>? yes
    Free inodes count wrong for group #64 (869, counted=874).
    Fix<y>? yes
    Free inodes count wrong for group #96 (2772, counted=2773).
    Fix<y>? yes
    Free inodes count wrong (2511328, counted=2511295).
    Fix<y>? yes
    Block bitmap differences: Group 97 block bitmap does not match checksum.
    FIXED.
    Recreate journal ('a' enables 'yes' to all) <y>? yes to all
    Creating journal (65536 blocks):  Done.
    
    *** journal has been regenerated ***
    
    /dev/mapper/loop0p2: ***** FILE SYSTEM WAS MODIFIED *****
    /dev/mapper/loop0p2: 175681/2686976 files (0.6% non-contiguous), 4559464/10746624 blocks
  root@virtual3:~# resize2fs /dev/mapper/loop0p2   <<<< NB webpage refers /dev/nbd0
    resize2fs 1.45.5 (07-Jan-2020)
    Resizing the filesystem on /dev/mapper/loop0p2 to 13106683 (4k) blocks.
    The filesystem on /dev/mapper/loop0p2 is now 13106683 (4k) blocks long.
    
  root@virtual3:~# tune2fs -j /dev/mapper/loop0p2
    tune2fs 1.45.5 (07-Jan-2020)
    The filesystem already has a journal.
  root@virtual3:~# kpartx -dv /dev/loop0
    del devmap : loop0p2
    del devmap : loop0p1
  root@virtual3:~# losetup -d /dev/loop0
  root@virtual3:~# virsh start nstest

 Guest failed to boot properly !!!

The guest dropped to a rescue shell, from which I did:

fsck /dev/vda2

(logged in via remote desktop viewer.) Several inconsistencies were fixed. This might have been my own problem - hopefully not yours! Guest will now boot but still only 41G ........ now to try again!

root@virtual3:~# virsh start nstest

THEN logged into guest via ssh:

  root@ns:~# resize2fs /dev/vda2
    resize2fs 1.45.5 (07-Jan-2020)
    Filesystem at /dev/vda2 is mounted on /; on-line resizing required
    old_desc_blocks = 6, new_desc_blocks = 7
    The filesystem on /dev/vda2 is now 13106683 (4k) blocks long.
    
  root@ns:~# df -h
    Filesystem      Size  Used Avail Use% Mounted on
     ...... snip .......
    /dev/vda2        49G   17G   31G  36% /

SUCCESS!

0 + 0

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: moving KVM image from one server to another and then resize

TH: ย้ายอิมเมจ KVM จากเซิร์ฟเวอร์หนึ่งไปยังอีกเซิร์ฟเวอร์หนึ่งแล้วปรับขนาด

RO: mutarea imaginii KVM de la un server la altul și apoi redimensionarea

RU: перемещение изображения KVM с одного сервера на другой, а затем изменение размера

VI: di chuyển hình ảnh KVM từ máy chủ này sang máy chủ khác rồi thay đổi kích thước

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.