Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
If a host attempts to detach a block device from a guest then xen-blkfront, will say "no, in use", and then do some setup for a deferred detach. On unmount that detach will occur. With RHEL5 tools if this is done, then first the tools see the "no, in use" and give up. After the unmount the block device goes to Closed (state==6), viewable with 'xm block-list'. Now that the device is in this state it gets stuck. The host no longer can completely detach it, or reattach it. We may want to fix this in the xen tools (I'm cloning this bug to xen as well), but even if we do, then we need to make sure that when rhel7 guests are run on older hosts without the tools fix, that we don't cause problems, particularly problems that may lead to disk corruption. This bug will be TestOnly for starters.
Comment 1Miroslav Rezanina
2012-07-03 13:52:12 UTC
With fix for 794806, device is properly removed from the guest without any freeze Unfortunately, it stays in xenstore (in state==6) so disk can't be re-attached. This require xend restart.
Vitaly tested this over EC2 with the following steps
0) attach volume 1) mount volume 2) detach volume 3) see if volume still works 4) umount volume 5) see if you can mount it again - shouldn't be able to 6) attach volume 7) mount volume 8) confirm no data corruption
for a rhel6 guest he found that it worked, but a delay of several seconds was needed between steps (4) and (5), likely because xenstore gets polled somewhat slowly for this feature. Then he tried with an F18 kernel and found problems
(01:33:18 PM) vkuznets: with f18 (3.6.10-4.fc18.x86_64) the behavior is different: "umount /mnt/ && mount /dev/xvdk /mnt/ " just hanged
(01:33:37 PM) vkuznets: with nothing in dmesg
(01:35:07 PM) vkuznets: umount hanged
(01:35:25 PM) vkuznets: the volume was unmounted
(01:35:37 PM) vkuznets: and I can see /dev/xvdk present
(01:40:03 PM) vkuznets: re-checked after reboot, the behavior is the same - 'umount' hangs
So I'm removing the TestOnly keyword as it looks like we'll need to write a patch for upstream to get this working.