Description of problem: When running vhostmd on a RHEL 5.4 system with XEN, vhostmd is not able to gather the VM metrics for the XEN guests. The system is using LibVirt and not the native XEN tools to manage the guest VMs. Version-Release number of selected component (if applicable): vhostmd-0.4-0.8.gite9db007b.el5_3 How reproducible: ALWAYS Steps to Reproduce: 1. set up XEN host and guest on RHEL5.4 2. Install vhostmd on host 3. run vm-dump-metrics on guest (or do $ cat /dev/shm/vhostmd0 on host) Actual results: $ cat /dev/shm/vhostmd0 mvbd���<metrics> <metric type='uint64' context='host'> <name>PageInRate</name> <value>8.000000</value> </metric> <metric type='uint64' context='host'> <name>PageFaultRate</name> <value>112.000000</value> </metric> <metric type='uint64' context='host'> <name>PagedOutMemory</name> <value>46 </value> </metric> <metric type='uint64' context='host'> <name>PagedInMemory</name> <value>390 </value> </metric> <metric type='uint64' context='host'> <name>UsedVirtualMemory</name> <value> 1318 </value> </metric> <metric type='uint64' context='host'> <name>FreeVirtualMemory</name> <value> 53977 </value> </metric> <metric type='uint64' context='host'> <name>UsedPhysicalMemory</name> <value> 1318 </value> </metric> <metric type='uint64' context='host'> <name>FreePhysicalMemory</name> <value> 31449 </value> </metric> <metric type='uint32' context='host'> <name>NumberOfPhysicalCPUsUtilized</name> <value>16 </value> </metric> <metric type='string' context='host'> <name>HostSystemInfo</name> <value>ls3055 </value> </metric> <metric type='string' context='host'> <name>VirtProductInfo</name> <value>QEMU 0.6.3 </value> </metric> <metric type='string' context='host'> <name>VirtualizationVendor</name> <value>Red Hat, Inc. Red Hat, Inc. </value> </metric> <metric type='string' context='host'> <name>HostName</name> <value>ls3055 </value> </metric> </metrics> cs> Expected results: This is the output from the same system, but using KVM instead of XEN: $cat /dev/shm/vhostmd0 mvbd <metric type='uint64' context='host'> <name>PageInRate</name> <value>0.000000</value> </metric> <metric type='uint64' context='host'> <name>PageFaultRate</name> <value>0.000000</value> </metric> <metric type='uint64' context='host'> <name>PagedOutMemory</name> <value>109 </value> </metric> <metric type='uint64' context='host'> <name>PagedInMemory</name> <value>483 </value> </metric> <metric type='uint64' context='host'> <name>UsedVirtualMemory</name> <value> 1090 </value> </metric> <metric type='uint64' context='host'> <name>FreeVirtualMemory</name> <value> 93871 </value> </metric> <metric type='uint64' context='host'> <name>UsedPhysicalMemory</name> <value> 1091 </value> </metric> <metric type='uint64' context='host'> <name>FreePhysicalMemory</name> <value> 71343 </value> </metric> <metric type='uint32' context='host'> <name>NumberOfPhysicalCPUsUtilized</name> <value>16 </value> </metric> <metric type='string' context='host'> <name>HostSystemInfo</name> <value>ls3055 </value> </metric> <metric type='string' context='host'> <name>VirtProductInfo</name> <value>QEMU 0.6.3 </value> </metric> <metric type='string' context='host'> <name>VirtualizationVendor</name> <value>Red Hat, Inc. Red Hat, Inc. </value> </metric> <metric type='string' context='host'> <name>HostName</name> <value>ls3055 </value> </metric> <metric type='uint64' context='vm' id='1' uuid='419d0898-8561-dc0e-dc58-0a6098e7314a'> <name>PhysicalMemoryAllocatedToVirtualSystem</name> <value>4096 </value> </metric> <metric type='uint32' context='vm' id='1' uuid='419d0898-8561-dc0e-dc58-0a6098e7314a'> <name>NumberOfAssignedPhysicalCPUs</name> <value>4 </value> </metric> <metric type='real64' context='vm' id='1' uuid='419d0898-8561-dc0e-dc58-0a6098e7314a'> <name>TotalCPUTime</name> <value>48.3s </value> </metric> </metrics> Additional info:
I forgot to mention that running "virsh" on the commandline will return the required values for the guest: [root@ls3055 ~]# virsh dominfo ls3055v1 Id: 1 Name: ls3055v1 UUID: 3dba9c47-0bfc-f0f0-cd03-78b2e2557386 OS Type: hvm State: idle CPU(s): 4 CPU time: 110.4s Max memory: 4210688 kB Used memory: 4202372 kB Autostart: disable
Bumped severity & priority up because I need to fix this one today for RHEL.
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
The problem here is that the daemon is reading the wrong libvirt hypervisor: <metric type='string' context='host'> <name>VirtProductInfo</name> <value>QEMU 0.6.3</value> </metric> Changing in /etc/sysconfig/vhostmd: VHOSTMD_URI=xen:/// Well, at the moment that just breaks things a whole lot more. I'm going to look at this more tomorrow morning.
No! Actually that works, it was just being slow to update the file. I'm not sure if this is exactly a bug, but I'll have a look again tomorrow.
Built for F-13: http://koji.fedoraproject.org/koji/taskinfo?taskID=1811237 Built for F-12: http://koji.fedoraproject.org/koji/taskinfo?taskID=1811251 As usual this fails on EL-5: http://koji.fedoraproject.org/koji/taskinfo?taskID=1811249 because of: https://fedorahosted.org/rel-eng/ticket/2982
vhostmd-0.4-0.6.gite9db007b.fc12.1 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/vhostmd-0.4-0.6.gite9db007b.fc12.1
The new build fixes the problem. Thanks for the quick fix.
vhostmd-0.4-0.6.gite9db007b.fc12.1 has been pushed to the Fedora 12 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update vhostmd'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2009-11642
The VERIFIED, FAILS_QA and RELEASE_PENDING bug states are not used by Fedora (they are used in the RHEL process). --- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
vhostmd-0.4-0.6.gite9db007b.fc12.1 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.