4:55 p.m.
If I updates code in the suits/libvirt-cim/lib/XenKvmLib/vxml.py,
uncomment ctltype="usb", ctlindex=0, ctlmodel=None):
and comment ctltype="pci", ctlindex=0, ctlmodel="pci-root"):
(Because you said that it's optional), some other failed testcases
appeared. It's obvious that these two testcases are caused by that
change.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
VirtualSystemSettingDataComponent - 02_reverse.py: FAIL
ERROR - RASD instances don't match expect=8 found=7.
ERROR - rasd_list ('pci_rasd','VSSDC_dom/controller:pci:0') not in
found_list
SystemDevice - 01_forward.py: FAIL
01_forward.py:29: DeprecationWarning: the sets module is deprecated
from sets import Set
ERROR - DeviceID mismatch
ERROR - Exception Expected DeviceID:
['test_domain/controller:pci:0', 'test_domain/controller:usb:0']
Got: [u'test_domain/controller:usb:0']
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Here is another failed testcase,
VirtualSystemManagementService - 09_procrasd_persist.py: FAIL
ERROR - Limit is None, expected 512
ERROR - Exception: details CPU scheduling not set properly for
defined dom: procrasd_persist_dom
Limit field was missed, from the new patches introduced. I'll continue
to debug and update my status at
any time.
Thanks,
Xu Wang
? 2014?04?22? 16:41, Xu Wang ??:
FYI. Maybe my original guess is right...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
PCI controllers have an optional|model|attribute with possible
values|pci-root|,|pcie-root|,|pci-bridge|, or|dmi-to-pci-bridge|. The
root controllers (|pci-root|and|pcie-root|) have an
optional|pcihole64|element specifying how big (in kilobytes, or in the
unit specified by|pcihole64|'s|unit|attribute) the 64-bit PCI hole
should be. Some guests (like Windows XP or Windows Server 2003) might
crash when QEMU and Seabios are recent enough to support 64-bit PCI
holes, unless this is disabled (set to 0).Since 1.1.2 (QEMU only)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The description above is from http://libvirt.org
/formatdomain.html#elementsControllers.
Thanks,
Xu Wang
? 2014?04?22? 11:22, Xu Wang ??:
> I am sorry it may not be caused by the version of qemu-kvm. But I
> still have not found the real reason. If you know it please let me know.
>
> Thanks,
> Xu Wang
> ? 2014?04?22? 10:59, Xu Wang ??:
>> Dear John,
>> I just found an issue on RHEL-6.5. The reproduce steps,
>> 1. Install a pure RHEL-6.5 system and just use rhn updates from RedHat.
>> 2. Install and config libvirt-cim/cimtest just like before.
>> 3. Run cimtest, you will find lots of testcases failed like this,
>> InvodeMethod(DefineSystem): CIM_ERR_FAILED: Failed to define domain:
>> internal error Unknown controller type 'pci' with return code 1
>>
>> The root cause of error is, default version of qemu-kvm from
>> RHEL-6.5 is 0.12.1.2-2,
>> too old for <controller type='pci' ...> (got that conclusion from
>> link http://libvirt.org
>> /formatdomain.html#elementsControllers). In my opinion, we should
>> take it into consideration,
>> or things like that will happen to the users who installed system
>> like that because not everyone
>> will update qemu to the newer version. My suggestion is, shall we
>> adjust cimtest a little?
>> Add a version checking into cimtest or just use another parameter
>> replace it (type='pci')?
>>
>> Thanks,
>> Xu Wang
>> ? 2014?04?22? 00:21, John Ferlan ??:
>>>
>>> Do you feel outside of patch 1/10 that this series can be pushed once
>>> the controller series is pushed? With of course any "adjustments"
to
>>> the numbers based on the libvirt-cim commit numbers.
>>>
>>> I can hold off on 1/10 and rework it later as there's just other
>>> things
>>> going on and I don't have the same issue since I don't use aliases
>>> on my
>>> localhost.
>>>
>>> Thanks,
>>>
>>> John
>>>
>>
>> _______________________________________________
>> Libvirt-cim mailing list
>> Libvirt-cim(a)redhat.com
>> https://www.redhat.com/mailman/listinfo/libvirt-cim
>
> _______________________________________________
> Libvirt-cim mailing list
> Libvirt-cim(a)redhat.com
> https://www.redhat.com/mailman/listinfo/libvirt-cim
_______________________________________________
Libvirt-cim mailing list
Libvirt-cim(a)redhat.com
https://www.redhat.com/mailman/listinfo/libvirt-cim