Bug 906766
| Summary: | virt-resize cannot resize RHEL 5 guest with GPT partition table type | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Community] Virtualization Tools | Reporter: | Arun S A G <sagarun> | ||||
| Component: | libguestfs | Assignee: | Richard W.M. Jones <rjones> | ||||
| Status: | CLOSED UPSTREAM | QA Contact: | |||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | unspecified | CC: | mbooth, ptoscano, rbalakri, rjones, virt-maint | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2016-05-09 10:00:26 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
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. 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 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. Isn't this a similar case to bug 1060404? The fixes for it were in libguestfs >= 1.25.33. 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. |
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: