Bug 193931 - xm top does not refresh after domain rename
xm top does not refresh after domain rename
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: xen (Show other bugs)
5
All Linux
medium Severity medium
: ---
: ---
Assigned To: Xen Maintainance List
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-06-02 20:22 EDT by Evan McNabb
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-03-26 16:30:57 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Evan McNabb 2006-06-02 20:22:27 EDT
Description of problem:
If 'xm top' is running and a guest domain is renamed, 'xm top' does not show the
new name. If 'xm top' is restarted, it still shows the incorrect name. All other
xm functions (e.g. 'xm list') use the correct name.

Version-Release number of selected component (if applicable):
Tested on kernel-xen0-2.6.16-1.2122_FC5 and xen-3.0.2-0.FC5.3

How reproducible:
always

Steps to Reproduce:
In terminal A:
# xm top
In terminal B:
# xm list
Name                              ID Mem(MiB) VCPUs State  Time(s)
Domain-0                           0      700     1 r-----    55.4
fc5                                2      300     1 -b----     7.9
# xm rename fc5 fc5new
# xm list
Name                              ID Mem(MiB) VCPUs State  Time(s)
Domain-0                           0      700     1 r-----    55.9
fc5new                             2      300     1 -b----     7.9

Actual results:
Terminal A's 'xm top' still shows 'fc5', even when restarted.

Expected results:
Terminal A's 'xm top' should show fc5new.
Comment 1 Evan McNabb 2006-06-14 10:02:30 EDT
Once the guest domain is rebooted, 'xm top' refreshes to the new (correct) name.
Comment 2 Daniel Berrange 2007-03-26 16:25:42 EDT
I have confirmed this problem on latest FC5 xen-3.0.3 tree. Even quitting &
restarting  'xm top' doesn't pick up the new name.

I strace'd the xm top process to find out where it was fetching the name
information from. 

socket(PF_FILE, SOCK_STREAM, 0)         = 4
connect(4, {sa_family=AF_FILE, path="/var/run/xenstored/socket_ro"}, 110) = 0
....some time later....
write(4, "\2\0\0\0\0\0\0\0\0\0\0\0\25\0\0\0", 16) = 16
write(4, "/local/domain/0/name\0", 21)  = 21
read(4, "\2\0\0\0\0\0\0\0\0\0\0\0\10\0\0\0", 16) = 16
read(4, "Domain-0", 8)                  = 8
write(4, "\2\0\0\0\0\0\0\0\0\0\0\0\25\0\0\0", 16) = 16
write(4, "/local/domain/4/name\0", 21)  = 21
read(4, "\2\0\0\0\0\0\0\0\0\0\0\0\v\0\0\0", 16) = 16
read(4, "rhel4x86_64", 11)              = 11

So its getting the name 'rhel4x86_64' from XenStore, even though I renamed it to
be 'wizz'. And indeed XenStore node is wrong:

# xenstore-read /local/domain/4/name
rhel4x86_64


So when performing the 'xm rename' XenD is failing to update XenStore records.
Comment 3 Daniel Berrange 2007-03-26 16:30:57 EDT
Latest Xen 3.0.4  in rawhide has this issue fixed, however, due to massive
internal re-write of XenD it is not practical to backport the fix to FC5/6.

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