Bug 906766 - virt-resize cannot resize RHEL 5 guest with GPT partition table type
Summary: virt-resize cannot resize RHEL 5 guest with GPT partition table type
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Virtualization Tools
Classification: Community
Component: libguestfs
Version: unspecified
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Richard W.M. Jones
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-02-01 12:41 UTC by Arun S A G
Modified: 2016-05-09 10:00 UTC (History)
5 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2016-05-09 10:00:26 UTC
Embargoed:


Attachments (Terms of Use)
Log file while running virt-edit with debug option (135.97 KB, text/plain)
2013-02-01 12:41 UTC, Arun S A G
no flags Details

Description Arun S A G 2013-02-01 12:41:23 UTC
Created attachment 691572 [details]
Log file while running virt-edit with debug option

Description of problem:
After running virt-resize on an existing VM the new disk doesn't boot!

Version-Release number of selected component (if applicable):
[saga@gnubox-dr]$ cat /etc/redhat-release 
Red Hat Enterprise Linux Server release 5.9 (Tikanga)
[saga@gnubox-dr]$ virt-resize --version
virt-resize 1.19.37
[saga@gnubox-dr]$ rpm -qf /usr/bin/virt-resize 
libguestfs-tools-c-1.19.37-4.el5


How reproducible:
Always

Steps to Reproduce:

1. Create a VM (RHEL4,RHEL5, RHEL6) (VM uses LVM for swap and root directory except boot, /dev/sda1 is used for /boot)

2. Resize its harddisk using virt-resize
qemu-img create -f raw newimage 50G
virt-resize --expand /dev/sda2 oldimage newimage
virsh edit domain (edit and switch to the newimage)

3. Start the VM (VM won't work)
  
Actual results:

VM just doesn't start


Expected results:

VM works normally!

Additional info:

Comment 1 Richard W.M. Jones 2013-02-04 12:51:19 UTC
virt-resize says that the guest uses GPT, which seems unlikely
since it is a RHEL 5 guest (right?).

Can you verify the partition table type of this guest so we know
if virt-resize/libguestfs made a mistake or not.

Comment 2 Arun S A G 2013-02-04 18:07:47 UTC
Here is the guest info:

[root@linux58 ~]# cat /etc/redhat-release 
Red Hat Enterprise Linux Server release 5.8 (Tikanga)
[root@linux58 ~]# 

[root@linux58 ~]# parted
GNU Parted 1.8.1
Using /dev/hda
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print                                                            

Model: QEMU HARDDISK (ide)
Disk /dev/hda: 8590MB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start   End     Size    File system  Name     Flags
 1      17.4kB  256MB   256MB   ext3         primary  boot 
 2      256MB   8590MB  8334MB               primary

Comment 3 Richard W.M. Jones 2013-02-04 20:55:21 UTC
I don't see any obvious problem with the copying steps.  However
because it's GPT we are not copying the GUID information across
(libguestfs didn't support guestfs_part_set_gpt_type/
guestfs_part_get_gpt_type until 1.20, and virt-resize still
doesn't attempt to use this).  Nor was virt-resize able to
set the MBR type byte in the protective MBR.

I'm going to suggest this is the reason why this guest won't boot.

Comment 4 Pino Toscano 2014-11-13 17:49:55 UTC
Isn't this a similar case to bug 1060404?  The fixes for it were in libguestfs >= 1.25.33.

Comment 5 Pino Toscano 2016-05-09 10:00:26 UTC
Other than bug #1060404, there were in the past months other commits to improve/fix virt-resize on GPT, like:
f630677c14c7d5528e1ab39e4f805e0957b2ee3e
dce3b4649deefc2fb5e1d069f084661b0cb62a0a

Marking as fixed, then -- please open new bugs, if there are still issues with virt-resize and GPT.


Note You need to log in before you can comment on or make changes to this bug.