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
[email protected]
https://www.redhat.com/mailman/listinfo/libvirt-cim
_______________________________________________
Libvirt-cim mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/libvirt-cim
_______________________________________________
Libvirt-cim mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/libvirt-cim
_______________________________________________
Libvirt-cim mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/libvirt-cim
