RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 618601 - We need to reopen images after migration
Summary: We need to reopen images after migration
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: qemu-kvm
Version: 6.0
Hardware: All
OS: Linux
low
high
Target Milestone: rc
: ---
Assignee: Juan Quintela
QA Contact: Virtualization Bugs
URL:
Whiteboard:
: 614286 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-07-27 11:02 UTC by Juan Quintela
Modified: 2013-01-09 22:57 UTC (History)
10 users (show)

Fixed In Version: qemu-kvm-0.12.1.2-2.106.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-11-10 21:26:58 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
target guest complaining about missing disk in drive (55.07 KB, image/jpeg)
2010-07-28 18:20 UTC, Luiz Capitulino 		no flags Details
"No Drive" Screen dumped. (244.79 KB, image/png)
2010-08-03 05:48 UTC, Mike Cao 		no flags Details
rhel6 fail screen dump (11.73 KB, image/png)
2010-08-03 06:23 UTC, Mike Cao 		no flags Details
View All

Description Juan Quintela 2010-07-27 11:02:49 UTC 
Description of problem:

qemu opens images at init time, but with NFS shared images, we need close-to-open semantics.  I.e. after migration ends, we need to:
- close images in source
- close images in target
- re-open images in target

to be sure that we get the latest info.

Version-Release number of selected component (if applicable):

All.

This is a regression from rhel5.  Patch was:
http://harpoon.virt.bos.redhat.com/~ehabkost/kvm-patches/kvm-Reopen-block-drivers-after-migration.patch
Comment 4 Dor Laor 2010-07-28 11:33:36 UTC 
*** Bug 614286 has been marked as a duplicate of this bug. ***
Comment 5 Luiz Capitulino 2010-07-28 18:20:16 UTC 
Created attachment 435101 [details]
target guest complaining about missing disk in drive

I was testing a quick and dirty version of this fix for rhel6 to ensure that bug 614286 is fixed and turns out that if you migrate during windows 2008 install (at the "expeding windows file" step) the target guest will complain that there's no DVD in the drive when it resumes, as shown by the attached screenshot.

By clicking in retry, windows seems to find the DVD and go ahead with the installation (which is far better than getting an corrupted image), however we might want to only reopen read-write images..

I'll wait for Juan's final submission to retest this (he said he's working on this).

PS: For details on the test setup and procedure see bug 614286, specially comment 22.
Comment 8 Luiz Capitulino 2010-07-30 12:54:33 UTC 
Some test considerations for this issue:

o Please, test other forms of migration too (eg. to file)
o Test migration during rhel6 installation too
o Check bug 614286 and comment 5 of this BZ
Comment 10 Mike Cao 2010-08-03 05:46:26 UTC 
Re-test it in qemu-kvm-0.12.1.2-2.106.el6    .

According to comment #8,


1.test migration via compressed file and std file . 
results:After migration ,guest sitll can be used


2.Repeat steps in bug 614286.
results:After migration ,Guest still can finish installation.When the guest start to the login screen. a message prompts "No Drive" in the guest.
Comment 11 Mike Cao 2010-08-03 05:48:05 UTC 
Created attachment 436188 [details]
"No Drive" Screen dumped.
Comment 12 Mike Cao 2010-08-03 06:22:23 UTC 
Re-tested in qemu-kvm-0.12.1.2-2.106.el6 .

Test migration during rhel6 guest installation

Actual Results:

Test several times,2 times failed.but the Actual result are different

failed scenario1 :
Migration failed and qemu-kvm quit in the dest host.
the message prompts:
qemu: warning :error whild loading state for instance 0x5 of device 'cpu'
load of migration failed.

2.failed scenario 2(rhel6 fail screen dump):
After migration ,in the Guest can not continue installation and it shows
"Running anaconda 13.21.60,the Redhat Enterprise Linux system installer -please wait
 05:04:50 Starting graphical installation.
 Fatal python error :GC object already tracked .
 Anaconda died after receiving signal 6.
 install exited abnormally [1/1]
 The System will be rebooted when you press Ctrl-C or Ctrl-Alt-Delete."

Additional info :

Don't know how to reproduce it.It seems that when the migration finished while the the guest is still formating system may trigger the issue.
Comment 13 Mike Cao 2010-08-03 06:23:58 UTC 
Created attachment 436191 [details]
rhel6 fail screen dump
Comment 14 Mike Cao 2010-08-03 08:55:07 UTC 
According to comment #12, May I re-assign this issue?.
Comment 15 Dor Laor 2010-08-03 10:51:53 UTC 
*** Bug 618509 has been marked as a duplicate of this bug. ***
Comment 16 Luiz Capitulino 2010-08-03 12:49:32 UTC 
It seems to me that both new issues (comment 11, comment 12 and comment 13) are not related to the reopening of images. Maybe they are two different bugs.

One way of confirming this would be to try to reproduce both problems on an older qemu-kvm package version, like qemu-kvm-0.12.1.2-2.91.el6.x86_64, which doesn't have the fix applied.

If you manage to reproduce the problems there, then we should close this BZ as verified and open new ones for the recently discovered issues.

Nice testing Mike!
Comment 17 Juan Quintela 2010-08-06 13:33:08 UTC 
I think that the two new issues appeared are new, not related with this bug.  Trying to reproduce.
Comment 18 Mike Cao 2010-08-09 10:01:14 UTC 
(In reply to comment #16)
> It seems to me that both new issues (comment 11, comment 12 and comment 13) are
> not related to the reopening of images. Maybe they are two different bugs.

Could you supply me how to comfirm that the patches has worked already ?

> One way of confirming this would be to try to reproduce both problems on an
> older qemu-kvm package version, like qemu-kvm-0.12.1.2-2.91.el6.x86_64, which
> doesn't have the fix applied.


The issues described in comment #11,comment #12, comment #13 were found by repeating the steps of bug 614286 .If using older qemu-kvm package to reproduce the problems above ,It will trigger bug 614286. Would you provide some advice how to comfirm whether they are new issues or not ?
Comment 19 jason wang 2010-08-10 06:19:10 UTC 
(In reply to comment #18)
> (In reply to comment #16)
> > It seems to me that both new issues (comment 11, comment 12 and comment 13) are
> > not related to the reopening of images. Maybe they are two different bugs.
> 
> Could you supply me how to comfirm that the patches has worked already ?
> 

What does the patche do is to reopen images after migration in destination, so  you could use strace -fe trace=open,close /usr/libexec/qemu ... and see whether images have been reopened after migration when you do the verification accroding to the steps of bug 614286.

> > One way of confirming this would be to try to reproduce both problems on an
> > older qemu-kvm package version, like qemu-kvm-0.12.1.2-2.91.el6.x86_64, which
> > doesn't have the fix applied.
> 
> 
> The issues described in comment #11,comment #12, comment #13 were found by
> repeating the steps of bug 614286 .If using older qemu-kvm package to reproduce
> the problems above ,It will trigger bug 614286. Would you provide some advice
> how to comfirm whether they are new issues or not ?    

The patch could resovle the issue of bug 614286, and the issuse you found in comment #11, comment #12 and comment #13 looks not related to the images re-open, if you could reproduce it, you should open new bzs.
Comment 20 Mike Cao 2010-08-11 02:42:46 UTC 
Re-tested in qemu-kvm-0.12.1.2-2.108.el6.

Repeat steps in comment #19 ,test live migration ,migration via compressed file.migration via dd.

Actual Results:
After migration ,it shows 

[pid 16606] open("/home/RHEL.raw", O_RDONLY|O_NONBLOCK) = 10
[pid 16606] close(10)                   = 0
[pid 16606] open("/home/RHEL.raw", O_RDWR|O_DIRECT|O_CLOEXEC) = 10
[pid 16606] close(16)

Change status to VERIFIED.
Comment 23 releng-rhel@redhat.com 2010-11-10 21:26:58 UTC 
Red Hat Enterprise Linux 6.0 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.
Note You need to log in before you can comment on or make changes to this bug.