Bug 494811 - "migrating-" prefix is not removed from guest's name when migration or xm save fails
"migrating-" prefix is not removed from guest's name when migration or xm sav...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: xen (Show other bugs)
5.4
All Linux
low Severity medium
: rc
: ---
Assigned To: Michal Novotny
Virtualization Bugs
:
Depends On: 513335
Blocks: 514500
  Show dependency treegraph
 
Reported: 2009-04-08 04:27 EDT by Jiri Denemark
Modified: 2014-02-02 17:37 EST (History)
11 users (show)

See Also:
Fixed In Version: xen-3.0.3-107.el5
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-01-13 17:16:34 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Fix to rename domain after failed save/migration (922 bytes, patch)
2009-08-20 05:58 EDT, Michal Novotny
no flags Details | Diff
Patch for the latest codebase (2.75 KB, patch)
2010-02-11 06:38 EST, Michal Novotny
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:0031 normal SHIPPED_LIVE xen bug fix and enhancement update 2011-01-12 10:59:24 EST

  None (edit)
Description Jiri Denemark 2009-04-08 04:27:22 EDT
Description of problem:
When xm save or a migration of a guest fails, guest's name is not reset to its original name. Everything but xm list still shows the domain as migrating-*

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

xen-3.0.3-80.el5, xen-3.0.3-83.el5

How reproducible:

Everytime

Steps to Reproduce:
1. create a PV guest
2. xm save guest /mnt/small/guest.save # so that it fails because of insufficient space
3. xentop; xenstore-ls
  
Actual results:

The guest is shown as migrating-* by xentop. The same name can be seen in xenstore.

Expected results:

The name of the guest should be reset to its original name without "migrating-" prefix.

Additional info:
Comment 1 Michal Novotny 2009-08-20 05:58:40 EDT
Created attachment 358062 [details]
Fix to rename domain after failed save/migration

This is the patch to rename the domain after failed save/migration. It's necessary to have patch for BZ #513335 applied first.
Comment 2 Michal Novotny 2010-02-11 06:38:43 EST
Created attachment 390222 [details]
Patch for the latest codebase

Hi,
this is the patch for our current codebase. Attached patch is patching mainly the forkHelper() method of XendCheckpoint.py script with option to pass dominfo object with domain information to it and if present and save is issued and failed, it restores the original guest name, i.e. it strips "migrating-" prefix from the guest's name.

It's been tested on x86_64 dom0 and for both 32-bit and 64-bit RHEL 5.3 HVM guests and 32-bit and 64-bit RHEL 5 PV guests. The HVM guest is not running after failed save but there is already a bug filed about that, BZ #486308 (HVM guest stops running when xm save fails). For PV guests the guest ends up in suspended state when save fails (which is the same behavior like before applying my patch).

Michal
Comment 5 Linqing Lu 2010-08-25 04:36:17 EDT
This bug has been verified in xen-3.0.3-115.el5
The PV guest runs WELL and the guest returns to its original name after "xm save" failed.

But still 2 further problems:
1- this guest will turn into zombie when trying "xm shut" it, just as the same
situation as Bug 589123.
2- if the PV guest has an PCI device assigned, the guest name will still have the "migrating-" prefix as Bug 627095.
Comment 7 errata-xmlrpc 2011-01-13 17:16:34 EST
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-0031.html

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