Bug 193931

Summary: xm top does not refresh after domain rename
Product: [Fedora] Fedora Reporter: Evan McNabb <emcnabb>
Component: xenAssignee: Xen Maintainance List <xen-maint>
Status: CLOSED RAWHIDE QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 5CC: bstein, katzj
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
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: ---

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:

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

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.