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.
Once the guest domain is rebooted, 'xm top' refreshes to the new (correct) name.
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.
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.