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