Bug 738221

Summary: [Regression][virt-manager] vm can not reboot which installed from HTTP with storage format qcow2
Product: Red Hat Enterprise Linux 6 Reporter: Daisy Wu <jwu>
Component: virt-managerAssignee: Cole Robinson <crobinso>
Status: CLOSED WORKSFORME QA Contact: Virtualization Bugs <virt-bugs>
Severity: high Docs Contact:
Priority: high    
Version: 6.2CC: jwu, mzhan, rwu, zpeng
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-12-09 22:34:54 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
debug info
none
screen none

Description Daisy Wu 2011-09-14 10:59:46 UTC
Description of problem:
vm can not reboot which installed from HTTP with storage format qcow2 

Version-Release number of selected component (if applicable):
virt-manager-0.9.0-6.el6
libvirt-0.9.4-11.el6
python-virtinst-0.600.0-3.el6
qemu-kvm-0.12.1.2-2.184.el6.x86_64

# uname -a
Linux localhost.localdomain 2.6.32-191.el6.x86_64 #1 SMP Wed Aug 17 20:22:22
EDT 2011 x86_64 x86_64 x86_64 GNU/Linux


How reproducible:
always

Steps to Reproduce:
1. Create image with qcow2 format:
   #qemu-img create -f qcow2 test1.img 8G
2. Click on the local connection.
3. Click NEW button at the top of Virtual Machine Manager dialog.
4. Fill out virtual machine name "test1" and select "Network Install(HTTP,FTP or NFS)",and Click "Forward" button.
5. Enter URL in "URL" field, such as http://download.englab.nay.redhat.com/pub/rhel/rel-eng/RHEL5.7-Server-20110409.3/tree-x86_64/
6. Check "Automatically detect operating system based on install media"
7. Click "Forward" button.
8. Select Memory and CPUs, and click Forward.
9. Check "Enable storage for this virtual machine",uncheck "Allocate entire disk now",check "Select managed or other existing storage",click "Browse" to open the test1.img
10. Click "Forward" button.
11. Open "Advanced options",uncheck "Set a fixed mac address",select the correct architecture according to the http url.Click "Customize configuration before install"
12. Click "Finish" button. Then Divert to guest virtual details page, Click DIsk and make sure the storage format is qcow2. Apply and Click Begin Installation.
13. Change NIC and Disk model to virtio.
14. Follow the into to install system.
15. After installation, the guest OS will reboot.
16. Check the status after reboot.

  
Actual results:
VM can not reboot correctly, guest hang on grub screen.

Expected results:
VM should reboot successfully after installation.

Additional info:
it's only occur when install rhel5.7 guest, for rhel6 guest, it worked well in above test enviromnet.
I can't reproduce this with:
libvirt-client-0.8.7-18.el6
qemu-kvm-0.12.1.2-2.160.el6
kernel-2.6.32-131.0.10.el6
so ,it should be a regression bug

Comment 2 Cole Robinson 2011-09-27 00:45:22 UTC
Is test1.img actually a qcow2 image? If it isn't, just changing the 'storage format' drop down in the details window is not going to work for you. If the image is a qcow2 image, you probably shouldn't need to tell that to virt-manager.

What exactly are you trying to do, create a guest with a new qcow2 disk? Can you post the output of virt-manager --debug when reproducing this issue?

Comment 3 Daisy Wu 2011-09-27 08:58:30 UTC
Update the detail steps of reproducing:
1. Create new image with qcow2 format:
   #qemu-img create -f qcow2 test2.img 8G
   qemu-img info test2.img 
   image: test2.img
   file format: qcow2
   virtual size: 8.0G (8589934592 bytes)
   disk size: 136K
   cluster_size: 65536
2. Click on the local connection.
3. Click NEW button at the top of Virtual Machine Manager dialog.
4. Fill out virtual machine name "test2" and select "Network Install(HTTP,FTP
or NFS)",and Click "Forward" button.
5. Enter URL in "URL" field, such as
http://download.englab.nay.redhat.com/pub/rhel/rel-eng/RHEL5.7-Server-20110409.3/tree-x86_64/
6. Check "Automatically detect operating system based on install media"
7. Click "Forward" button.
8. Select Memory and CPUs, and click Forward.
9. Check "Enable storage for this virtual machine",uncheck "Allocate entire
disk now",check "Select managed or other existing storage",click "Browse" to
open the test2.img
10. Click "Forward" button.
11. Open "Advanced options",uncheck "Set a fixed mac address",select the
correct architecture according to the http url.Click "Customize configuration
before install"
12. Click "Finish" button. Then Divert to guest virtual details page, Click
Disk and choose qcow2 for storage format(this option is blank default). Click Apply. 
13. Change NIC and Disk model to virtio.Click Apply. 
14. Click Begin Installation.
15. Follow the into to install system.
16. After installation, the guest OS will reboot.
17. Check the status after reboot.
VM can not reboot correctly, guest hang on grub screen.
Please review the attachment debug0927.log and screen.png for detail info.

Comment 4 Daisy Wu 2011-09-27 09:01:31 UTC
Created attachment 525056 [details]
debug info

Comment 5 Daisy Wu 2011-09-27 09:05:20 UTC
Created attachment 525059 [details]
screen

Comment 6 RHEL Program Management 2011-10-07 16:11:20 UTC
Since RHEL 6.2 External Beta has begun, and this bug remains
unresolved, it has been rejected as it is not proposed as
exception or blocker.

Red Hat invites you to ask your support representative to
propose this request, if appropriate and relevant, in the
next release of Red Hat Enterprise Linux.

Comment 7 Cole Robinson 2011-10-13 21:17:21 UTC
I can't reproduce this issue.

What's the output of qemu-img info <diskpath> after the install? How are you rebooting the guest, the virt-manager reboot button or the anaconda reboot button? Does the RHEL5 installer report any errors?

Deferring to 6.3 for now

Comment 9 Cole Robinson 2011-12-09 22:34:54 UTC
No response for a couple months. Closing as WORKSFORME. Daisy, if you can still reproduce, please reopen with the info requested in comment #7