Description of problem: MIQ(Class#log_dos_error_results) #< CLIXML error is found in evm.log and scvmm.log file Version-Release number of selected component (if applicable): 5.4.0.0.14.20150325124454_9e339f3 How reproducible: 100% Steps to Reproduce: 1. Add scvmm provider to the appliance 2. After sometime below mentioned error is observed in both scvmm.log and evm.log file Actual results: Expected results: Additional info: scvmm.log: ========== [----] I, [2015-04-10T05:34:18.842380 #8385:a37e9c] INFO -- : MIQ(EmsRefresh::Parsers::Scvmm.ems_inv_to_hashes) Collecting data for EMS name: [scvmm] id: [6]... [----] E, [2015-04-10T05:34:39.302308 #8385:a37e9c] ERROR -- : MIQ(Class#log_dos_error_results) #< CLIXML <Objs Version="1.1.0.1" xmlns="http://schemas.microsoft.com/powershell/2004/04"><Obj S="progress" RefId="0"><TN RefId="0"><T>System.Management.Automation.PSCustomObject</T><T>System.Object</T></TN><MS><I64 N="SourceId">1</I64><PR N="Record"><AV>Preparing modules for first use.</AV><AI>0</AI><Nil /><PI>-1</PI><PC>-1</PC><T>Completed</T><SR>-1</SR><SD> </SD></PR></MS></Obj><Obj S="progress" RefId="1"><TNRef RefId="0" /><MS><I64 N="SourceId">2</I64><PR N="Record"><AV>Preparing modules for first use.</AV><AI>0</AI><Nil /><PI>-1</PI><PC>-1</PC><T>Completed</T><SR>-1</SR><SD> </SD></PR></MS></Obj><S S="Error">Read-SCGuestInfo : Virtual machine testvm cannot be modified because Virtual _x000D__x000A_</S><S S="Error">Guest Services is not installed on the guest operating system or because the _x000D__x000A_</S><S S="Error">installed Virtual Guest Services does not support the Heartbeat and Data _x000D__x000A_</S><S S="Error">Exchange Integration Services in the current virtual machine status. (Error _x000D__x000A_</S><S S="Error">ID: 30101)_x000D__x000A_</S><S S="Error"> _x000D__x000A_</S><S S="Error">Verify the virtual machine is in a Running status, the Virtual Guest Services _x000D__x000A_</S><S S="Error">is installed, and the Heartbeat and Data Exchange Integration Services are _x000D__x000A_</S><S S="Error">enabled._x000D__x000A_</S><S S="Error">At line:14 char:16_x000D__x000A_</S><S S="Error">+ $networks = Read-SCGuestInfo -VM $_ -Key "NetworkAddressIPv4"_x000D__x000A_</S><S S="Error">+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~_x000D__x000A_</S><S S="Error"> + CategoryInfo : ReadError: (:) [Read-SCGuestInfo], CarmineExcept _x000D__x000A_</S><S S="Error"> ion_x000D__x000A_</S><S S="Error"> + FullyQualifiedErrorId : 30101,Microsoft.SystemCenter.VirtualMachineManag _x000D__x000A_</S><S S="Error"> er.Cmdlets.ReadScGuestInfoCmdlet_x000D__x000A_</S><Obj S="progress" RefId="2"><TNRef RefId="0" /><MS><I64 N="SourceId">3</I64><PR N="Record"><AV>Preparing modules for first use.</AV><AI>0</AI><Nil /><PI>-1</PI><PC>-1</PC><T>Completed</T><SR>-1</SR><SD> </SD></PR></MS></Obj><Obj S="progress" RefId="3"><TNRef RefId="0" /><MS><I64 N="SourceId">3</I64><PR N="Record"><AV>Preparing modules for first use.</AV><AI>0</AI><Nil /><PI>-1</PI><PC>-1</PC><T>Completed</T><SR>-1</SR><SD> </SD></PR></MS></Obj><Obj S="progress" RefId="4"><TNRef RefId="0" /><MS><I64 N="SourceId">3</I64><PR N="Record"><AV>Preparing modules for first use.</AV><AI>0</AI><Nil /><PI>-1</PI><PC>-1</PC><T>Completed</T><SR>-1</SR><SD> </SD></PR></MS></Obj><Obj S="progress" RefId="5"><TNRef RefId="0" /><MS><I64 N="SourceId">3</I64><PR N="Record"><AV>Preparing modules for first use.</AV><AI>0</AI><Nil /><PI>-1</PI><PC>-1</PC><T>Completed</T><SR>-1</SR><SD> </SD></PR></MS></Obj></Objs> [----] I, [2015-04-10T05:34:42.488678 #8385:a37e9c] INFO -- : MIQ(EmsRefresh::Parsers::Scvmm.ems_inv_to_hashes) Collecting data for EMS name: [scvmm] id: [6]...Complete
> Virtual machine testvm cannot be modified because Virtual Guest Services is not > installed on the guest operating system or because the installed Virtual Guest > Services does not support the Heartbeat and Data Exchange Integration Services > in the current virtual machine status Environment Problem?
Hi Ramesh, In order to get the networking information for a VM the guest services must be installed and running on the VM. This message means they are not. This does not indicate a bug, its just a very ugly logging that will soon be cleaned up. Can you verify all the inventory looks good other than empty IP address on the VM? If it does you can close this ticket. thanks
Hi Ramesh I have looked into this and the only problem I see is the CPUCOunt is 0 and I am investigating this. A couple of things to note: - the IP will be empty if the Integration Services are not running on a VM or if the VM is powered off. - If there is no OS installed (OS is "Unknown" in our UI) then there will be no hostname - Support hasn't been added for: CPU affinity, retirement state, service. - A lot of the VMs in the QE lab are half made and don't even have a VHD (in SCVMM go to: Settings/Hardware Configuration/IDE Devices") Can you elaborate on this question? I don't follow: "...Security, Configuration, Datastore allocations are different..." Different from what? thank-you
Jason, There were some changes made by you to display CPU details on VM summary and container information screen. I don't see a typo in there but maybe an incorrect method is being called to show CPU count, can you please help look into this. changes were made on 4/29, Commit SHA d5df5059, app/helpers/vm_helper/textual_summary.rb line 157 thru 164. Thanks, ~Harpreet
Can I get a screenshot of the error? I don't have SCVMM, and code-wise everything looks fine both from the parser and the UI code.
So, Greg, your comment above is sort of incorrect and that's what's been confusing me 2) The CPU count stored in the database is correct. It appears that just the UI is showing the value of 0. There are 3 columns we use: - numvpcus (Number of sockets) - cores_per_socket (Number of cores per socket) - logical_cpus (Should be numvcpus * cores_per_socket) In the UI the string of "8 CPUs (4 cores x 2 sockets)" is built from logical_cpus = 8, numvcpus = 4, cores_per_socket = 2. If either numvcpus or cores_per_socket is null you'll get just "8 CPUs". So, logical_cpus is the important number In the database used, both cores_per_socket and logical_cpus are null. Is that correct? Sounds like SCVMM is either not returning that value properly or we have a typo in the key name (because the code looks fine). If there is a chance that we can get nulls back, I think the parser has to handle that case and make sure that logical_cpus is filled in. Either that or we have to change the UI to present things differently when logical_cpus is null. What do you think?
I honestly don't remember now ... and the appliance is gone. If you have the appliance database I could look at it. However, glancing at https://github.com/ManageIQ/manageiq/blob/master/app/models/ems_refresh/parsers/scvmm.rb#L307, it looks like the SCVMM refresh parser is only setting "numvcpus". So, based on what you're saying, the parser is wrong and needs to set "logical_cpus" instead. Right? If so, I can put this back over to Bronagh to get a fix in the refresh parser.
Oh man...I was totally looking in the wrong place when I said that the code looked correct...I was looking at Hosts :| https://github.com/ManageIQ/manageiq/blob/master/app/models/ems_refresh/parsers/scvmm.rb#L243-L245 Also, there are actually 2 places that the hardware code needs fixing: https://github.com/ManageIQ/manageiq/blob/master/app/models/ems_refresh/parsers/scvmm.rb#L307 https://github.com/ManageIQ/manageiq/blob/master/app/models/ems_refresh/parsers/scvmm.rb#L218 It feels weird that similar looking code is in two places...it might need refactoring if possible as well.
https://github.com/ManageIQ/manageiq/pull/3884
New commit detected on manageiq/master: https://github.com/ManageIQ/manageiq/commit/be379d0dc793010fd9834b38cb277813069f99d9 commit be379d0dc793010fd9834b38cb277813069f99d9 Author: Greg Blomquist <gblomqui> AuthorDate: Fri Aug 14 16:41:03 2015 -0400 Commit: Greg Blomquist <gblomqui> CommitDate: Fri Aug 14 16:41:03 2015 -0400 [SCVMM] Parse CPUCount into logical_cpus The UI (and other places) use Vm#logical_cpus to indicate the number of CPUs available in a VM. Numbers like Vm#hardware#numvcpus and Vm#hardware#cores_per_socket help determine how Vm#logical_cpus is calculated. However, in the case of SCVMM there is only on CPUCount value returned when collecting inventory. So, defaulting this value to logical_cpus will at least show the number of CPUs the Vm has available even if the constituent parts are not known. https://bugzilla.redhat.com/show_bug.cgi?id=1210657 https://bugzilla.redhat.com/show_bug.cgi?id=1247655 app/models/ems_refresh/parsers/scvmm.rb | 4 ++-- spec/models/ems_refresh/refreshers/scvmm_refresher_spec.rb | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-)
New commit detected on cfme/5.4.z: https://code.engineering.redhat.com/gerrit/gitweb?p=cfme.git;a=commitdiff;h=7ae15842cb984523dcb688da31602793d6336d81 commit 7ae15842cb984523dcb688da31602793d6336d81 Author: Greg Blomquist <gblomqui> AuthorDate: Fri Aug 14 16:41:03 2015 -0400 Commit: Greg Blomquist <gblomqui> CommitDate: Tue Aug 18 13:28:53 2015 -0400 [SCVMM] Parse CPUCount into logical_cpus The UI (and other places) use Vm#logical_cpus to indicate the number of CPUs available in a VM. Numbers like Vm#hardware#numvcpus and Vm#hardware#cores_per_socket help determine how Vm#logical_cpus is calculated. However, in the case of SCVMM there is only on CPUCount value returned when collecting inventory. So, defaulting this value to logical_cpus will at least show the number of CPUs the Vm has available even if the constituent parts are not known. https://bugzilla.redhat.com/show_bug.cgi?id=1210657 https://bugzilla.redhat.com/show_bug.cgi?id=1247655 vmdb/app/models/ems_refresh/parsers/scvmm.rb | 4 ++-- vmdb/spec/models/ems_refresh/refreshers/scvmm_refresher_spec.rb | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-)
Good to go. Verified and working fine in 5.5.0.2-alpha1.1.20150923081748_2e8e945
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2015:2551