[Libvirt-cim] [PATCH 00/10] cimtest: changes for controller and upstream support

[Xu Wang]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvirt-cim/attachments/20140422/3c909c1a/attachment.htm>