7:39 p.m.
=================================================
KVM on Pegasus Test Run Summary for Sep 10 2008
=================================================
Distro: Fedora release 8.92 (Rawhide)
Kernel: 2.6.25-0.121.rc5.git4.fc9
libvirt: 0.4.4
Hypervisor: QEMU 0.9.1
CIMOM: Pegasus 2.7.0
Libvirt-cim revision: 680
Libvirt-cim changeset: e4e78fce7957
=================================================
FAIL : 2
XFAIL : 3
SKIP : 5
PASS : 125
-----------------
Total : 135
=================================================
FAIL Test Summary:
ComputerSystem - 23_suspend_suspend.py: FAIL
ReferencedProfile - 01_verify_refprof.py: FAIL
=================================================
XFAIL Test Summary:
ComputerSystem - 32_start_reboot.py: XFAIL
ComputerSystem - 33_suspend_reboot.py: XFAIL
ResourceAllocationFromPool - 05_RAPF_err.py: XFAIL
=================================================
SKIP Test Summary:
ComputerSystem - 02_nosystems.py: SKIP
VSSD - 02_bootldr.py: SKIP
VirtualSystemMigrationService - 01_migratable_host.py: SKIP
VirtualSystemMigrationService - 02_host_migrate_type.py: SKIP
VirtualSystemMigrationService - 05_migratable_host_errs.py: SKIP
=================================================
Full report:
--------------------------------------------------------------------
AllocationCapabilities - 01_enum.py: PASS
--------------------------------------------------------------------
AllocationCapabilities - 02_alloccap_gi_errs.py: PASS
--------------------------------------------------------------------
ComputerSystem - 01_enum.py: PASS
--------------------------------------------------------------------
ComputerSystem - 02_nosystems.py: SKIP
ERROR - System has defined domains; unable to run
--------------------------------------------------------------------
ComputerSystem - 03_defineVS.py: PASS
--------------------------------------------------------------------
ComputerSystem - 04_defineStartVS.py: PASS
--------------------------------------------------------------------
ComputerSystem - 05_activate_defined_start.py: PASS
--------------------------------------------------------------------
ComputerSystem - 06_paused_active_suspend.py: PASS
--------------------------------------------------------------------
ComputerSystem - 22_define_suspend.py: PASS
--------------------------------------------------------------------
ComputerSystem - 23_suspend_suspend.py: FAIL
ERROR - Exception: (1, u'CIM_ERR_FAILED: Invalid state transition')
ERROR - Unable to 'Start' dom 'cs_test_domain' using
RequestedStateChange()
InvokeMethod(RequestStateChange): CIM_ERR_FAILED: Invalid state transition
--------------------------------------------------------------------
ComputerSystem - 27_define_suspend_errs.py: PASS
--------------------------------------------------------------------
ComputerSystem - 32_start_reboot.py: XFAIL
ERROR - Exception: (1, u'CIM_ERR_FAILED: Domain Operation Failed')
ERROR - Unable to 'Reboot' dom 'cs_test_domain' using
RequestedStateChange()
InvokeMethod(RequestStateChange): CIM_ERR_FAILED: Domain Operation Failed
Bug:<00005>
--------------------------------------------------------------------
ComputerSystem - 33_suspend_reboot.py: XFAIL
ERROR - Exception: (1, u'CIM_ERR_FAILED: Domain Operation Failed')
ERROR - Unable to 'Reboot' dom 'test_domain' using
RequestedStateChange()
InvokeMethod(RequestStateChange): CIM_ERR_FAILED: Domain Operation Failed
Bug:<00005>
--------------------------------------------------------------------
ComputerSystem - 35_start_reset.py: PASS
--------------------------------------------------------------------
ComputerSystem - 40_RSC_start.py: PASS
--------------------------------------------------------------------
ComputerSystem - 41_cs_to_settingdefinestate.py: PASS
--------------------------------------------------------------------
ComputerSystem - 42_cs_gi_errs.py: PASS
--------------------------------------------------------------------
ComputerSystemIndication - 01_created_indication.py: PASS
--------------------------------------------------------------------
ElementAllocatedFromPool - 01_forward.py: PASS
--------------------------------------------------------------------
ElementAllocatedFromPool - 02_reverse.py: PASS
--------------------------------------------------------------------
ElementAllocatedFromPool - 03_reverse_errs.py: PASS
--------------------------------------------------------------------
ElementAllocatedFromPool - 04_forward_errs.py: PASS
--------------------------------------------------------------------
ElementCapabilities - 01_forward.py: PASS
--------------------------------------------------------------------
ElementCapabilities - 02_reverse.py: PASS
--------------------------------------------------------------------
ElementCapabilities - 03_forward_errs.py: PASS
--------------------------------------------------------------------
ElementCapabilities - 04_reverse_errs.py: PASS
--------------------------------------------------------------------
ElementCapabilities - 05_hostsystem_cap.py: PASS
--------------------------------------------------------------------
ElementConforms - 01_forward.py: PASS
--------------------------------------------------------------------
ElementConforms - 02_reverse.py: PASS
--------------------------------------------------------------------
ElementConforms - 03_ectp_fwd_errs.py: PASS
--------------------------------------------------------------------
ElementConforms - 04_ectp_rev_errs.py: PASS
--------------------------------------------------------------------
ElementSettingData - 01_forward.py: PASS
--------------------------------------------------------------------
ElementSettingData - 03_esd_assoc_with_rasd_errs.py: PASS
--------------------------------------------------------------------
EnabledLogicalElementCapabilities - 01_enum.py: PASS
--------------------------------------------------------------------
EnabledLogicalElementCapabilities - 02_elecap_gi_errs.py: PASS
--------------------------------------------------------------------
HostSystem - 01_enum.py: PASS
--------------------------------------------------------------------
HostSystem - 02_hostsystem_to_rasd.py: PASS
--------------------------------------------------------------------
HostSystem - 03_hs_to_settdefcap.py: PASS
--------------------------------------------------------------------
HostSystem - 04_hs_to_EAPF.py: PASS
--------------------------------------------------------------------
HostSystem - 05_hs_gi_errs.py: PASS
--------------------------------------------------------------------
HostSystem - 06_hs_to_vsms.py: PASS
--------------------------------------------------------------------
HostedDependency - 01_forward.py: PASS
--------------------------------------------------------------------
HostedDependency - 02_reverse.py: PASS
--------------------------------------------------------------------
HostedDependency - 03_enabledstate.py: PASS
--------------------------------------------------------------------
HostedDependency - 04_reverse_errs.py: PASS
--------------------------------------------------------------------
HostedResourcePool - 01_forward.py: PASS
--------------------------------------------------------------------
HostedResourcePool - 02_reverse.py: PASS
--------------------------------------------------------------------
HostedResourcePool - 03_forward_errs.py: PASS
--------------------------------------------------------------------
HostedResourcePool - 04_reverse_errs.py: PASS
--------------------------------------------------------------------
HostedService - 01_forward.py: PASS
--------------------------------------------------------------------
HostedService - 02_reverse.py: PASS
--------------------------------------------------------------------
HostedService - 03_forward_errs.py: PASS
--------------------------------------------------------------------
HostedService - 04_reverse_errs.py: PASS
--------------------------------------------------------------------
LogicalDisk - 01_disk.py: PASS
--------------------------------------------------------------------
LogicalDisk - 02_nodevs.py: PASS
--------------------------------------------------------------------
LogicalDisk - 03_ld_gi_errs.py: PASS
--------------------------------------------------------------------
Memory - 01_memory.py: PASS
--------------------------------------------------------------------
Memory - 02_defgetmem.py: PASS
--------------------------------------------------------------------
Memory - 03_mem_gi_errs.py: PASS
--------------------------------------------------------------------
NetworkPort - 01_netport.py: PASS
--------------------------------------------------------------------
NetworkPort - 02_np_gi_errors.py: PASS
--------------------------------------------------------------------
NetworkPort - 03_user_netport.py: PASS
--------------------------------------------------------------------
Processor - 01_processor.py: PASS
--------------------------------------------------------------------
Processor - 02_definesys_get_procs.py: PASS
--------------------------------------------------------------------
Processor - 03_proc_gi_errs.py: PASS
--------------------------------------------------------------------
Profile - 01_enum.py: PASS
--------------------------------------------------------------------
Profile - 02_profile_to_elec.py: PASS
--------------------------------------------------------------------
Profile - 03_rprofile_gi_errs.py: PASS
--------------------------------------------------------------------
RASD - 01_verify_rasd_fields.py: PASS
--------------------------------------------------------------------
RASD - 02_enum.py: PASS
--------------------------------------------------------------------
RASD - 03_rasd_errs.py: PASS
--------------------------------------------------------------------
RASD - 04_disk_rasd_size.py: PASS
--------------------------------------------------------------------
ReferencedProfile - 01_verify_refprof.py: FAIL
ERROR - InstanceID Mismatch
ERROR - Returned
CIM:DSP1059-GenericDeviceResourceVirtualization-1.0.0_d instead of
CIM:DSP1059-GenericDeviceResourceVirtualization-1.0.0
--------------------------------------------------------------------
ReferencedProfile - 02_refprofile_errs.py: PASS
--------------------------------------------------------------------
ResourceAllocationFromPool - 01_forward.py: PASS
--------------------------------------------------------------------
ResourceAllocationFromPool - 02_reverse.py: PASS
--------------------------------------------------------------------
ResourceAllocationFromPool - 03_forward_errs.py: PASS
--------------------------------------------------------------------
ResourceAllocationFromPool - 04_reverse_errs.py: PASS
--------------------------------------------------------------------
ResourceAllocationFromPool - 05_RAPF_err.py: XFAIL
ERROR - 'KVM_ResourceAllocationFromPool' association failed to
generate an exception and 'InstanceID' passed.
ERROR - ------FAILED: to verify the RAFP.------
Bug:<>
--------------------------------------------------------------------
ResourcePool - 01_enum.py: PASS
--------------------------------------------------------------------
ResourcePool - 02_rp_gi_errors.py: PASS
--------------------------------------------------------------------
ResourcePoolConfigurationCapabilities - 01_enum.py: PASS
--------------------------------------------------------------------
ResourcePoolConfigurationCapabilities - 02_rpcc_gi_errs.py: PASS
--------------------------------------------------------------------
ResourcePoolConfigurationService - 01_enum.py: PASS
--------------------------------------------------------------------
ResourcePoolConfigurationService - 02_rcps_gi_errors.py: PASS
--------------------------------------------------------------------
ResourcePoolConfigurationService - 03_CreateResourcePool.py: PASS
--------------------------------------------------------------------
ResourcePoolConfigurationService - 04_CreateChildResourcePool.py: PASS
--------------------------------------------------------------------
ResourcePoolConfigurationService - 05_AddResourcesToResourcePool.py: PASS
--------------------------------------------------------------------
ResourcePoolConfigurationService -
06_RemoveResourcesFromResourcePool.py: PASS
--------------------------------------------------------------------
ResourcePoolConfigurationService - 07_DeleteResourcePool.py: PASS
--------------------------------------------------------------------
SettingsDefine - 01_forward.py: PASS
--------------------------------------------------------------------
SettingsDefine - 02_reverse.py: PASS
--------------------------------------------------------------------
SettingsDefine - 03_sds_fwd_errs.py: PASS
--------------------------------------------------------------------
SettingsDefine - 04_sds_rev_errs.py: PASS
--------------------------------------------------------------------
SettingsDefineCapabilities - 01_forward.py: PASS
--------------------------------------------------------------------
SettingsDefineCapabilities - 03_forward_errs.py: PASS
--------------------------------------------------------------------
SettingsDefineCapabilities - 04_forward_vsmsdata.py: PASS
--------------------------------------------------------------------
SettingsDefineCapabilities - 05_reverse_vsmcap.py: PASS
--------------------------------------------------------------------
SystemDevice - 01_forward.py: PASS
--------------------------------------------------------------------
SystemDevice - 02_reverse.py: PASS
--------------------------------------------------------------------
SystemDevice - 03_fwderrs.py: PASS
--------------------------------------------------------------------
VSSD - 01_enum.py: PASS
--------------------------------------------------------------------
VSSD - 02_bootldr.py: SKIP
--------------------------------------------------------------------
VSSD - 03_vssd_gi_errs.py: PASS
--------------------------------------------------------------------
VSSD - 04_vssd_to_rasd.py: PASS
--------------------------------------------------------------------
VirtualSystemManagementCapabilities - 01_enum.py: PASS
--------------------------------------------------------------------
VirtualSystemManagementCapabilities - 02_vsmcap_gi_errs.py: PASS
--------------------------------------------------------------------
VirtualSystemManagementService - 01_definesystem_name.py: PASS
--------------------------------------------------------------------
VirtualSystemManagementService - 02_destroysystem.py: PASS
--------------------------------------------------------------------
VirtualSystemManagementService - 03_definesystem_ess.py: PASS
--------------------------------------------------------------------
VirtualSystemManagementService - 04_definesystem_ers.py: PASS
--------------------------------------------------------------------
VirtualSystemManagementService - 05_destroysystem_neg.py: PASS
--------------------------------------------------------------------
VirtualSystemManagementService - 06_addresource.py: PASS
--------------------------------------------------------------------
VirtualSystemManagementService - 07_addresource_neg.py: PASS
--------------------------------------------------------------------
VirtualSystemManagementService - 08_modifyresource.py: PASS
--------------------------------------------------------------------
VirtualSystemManagementService - 09_procrasd_persist.py: PASS
--------------------------------------------------------------------
VirtualSystemManagementService - 10_hv_version.py: PASS
--------------------------------------------------------------------
VirtualSystemManagementService - 11_define_memrasdunits.py: PASS
--------------------------------------------------------------------
VirtualSystemManagementService - 12_referenced_config.py: PASS
--------------------------------------------------------------------
VirtualSystemManagementService - 13_refconfig_additional_devs.py: PASS
--------------------------------------------------------------------
VirtualSystemMigrationCapabilities - 01_enum.py: PASS
--------------------------------------------------------------------
VirtualSystemMigrationCapabilities - 02_vsmc_gi_errs.py: PASS
--------------------------------------------------------------------
VirtualSystemMigrationService - 01_migratable_host.py: SKIP
--------------------------------------------------------------------
VirtualSystemMigrationService - 02_host_migrate_type.py: SKIP
--------------------------------------------------------------------
VirtualSystemMigrationService - 05_migratable_host_errs.py: SKIP
--------------------------------------------------------------------
VirtualSystemMigrationSettingData - 01_enum.py: PASS
--------------------------------------------------------------------
VirtualSystemMigrationSettingData - 02_vsmsd_gi_errs.py: PASS
--------------------------------------------------------------------
VirtualSystemSettingDataComponent - 01_forward.py: PASS
--------------------------------------------------------------------
VirtualSystemSettingDataComponent - 02_reverse.py: PASS
--------------------------------------------------------------------
VirtualSystemSettingDataComponent - 03_vssdc_fwd_errs.py: PASS
--------------------------------------------------------------------
VirtualSystemSettingDataComponent - 04_vssdc_rev_errs.py: PASS
--------------------------------------------------------------------
VirtualSystemSnapshotService - 01_enum.py: PASS
--------------------------------------------------------------------
VirtualSystemSnapshotService - 02_vs_sservice_gi_errs.py: PASS
--------------------------------------------------------------------
VirtualSystemSnapshotServiceCapabilities - 01_enum.py: PASS
--------------------------------------------------------------------
VirtualSystemSnapshotServiceCapabilities - 02_vs_sservicecap_gi_errs.py:
PASS
--------------------------------------------------------------------
Thanks and Regards,
Deepti.
8:24 p.m.
Deepti B Kalakeri wrote:
=================================================
KVM on Pegasus Test Run Summary for Sep 10 2008
=================================================
Distro: Fedora release 8.92 (Rawhide)
Kernel: 2.6.25-0.121.rc5.git4.fc9
libvirt: 0.4.4
Hypervisor: QEMU 0.9.1
CIMOM: Pegasus 2.7.0
Libvirt-cim revision: 680
Libvirt-cim changeset: e4e78fce7957
=================================================
FAIL : 2
XFAIL : 3
SKIP : 5
PASS : 125
-----------------
Total : 135
=================================================
FAIL Test Summary:
ComputerSystem - 23_suspend_suspend.py: FAIL
The above tc passed when run
manually.
ReferencedProfile - 01_verify_refprof.py: FAIL
This tc is
failing bcs of the recent provider changes and the test case
needs to be reworked.
Patch under work.
=================================================
XFAIL Test Summary:
ComputerSystem - 32_start_reboot.py: XFAIL
ComputerSystem - 33_suspend_reboot.py: XFAIL
ResourceAllocationFromPool - 05_RAPF_err.py: XFAIL
The above RAFP tc is written to
verify that RAFP returns appropriate
error when a non-existing bridge or networkpool is used in defining a guest.
But, the tc now XFAIL's because it returns a valid RAFP record.
This is due to the use of the cim_define() in the test case.
Before calling the cim_define() we make necessary changes to the XML
configuration to reflect the invalid bridge/networkpool name.
But when we use the cim_define() function we do not have any means where
we can use the invalid networkpool name or bridgename.
Hence the DefineSystem() in the cim_define() goes ahead to define a
guest with the valid networkpoolname and RAFP returns a record, which is
against the test case.
I ran the tc for Xen/XenFV and the tc fails there as well.
Can we revert back to the define() [which used virsh to define the
guest], which initially existed in the tc ??
Thanks and Regards,
Deepti.
4:04 a.m.
> =================================================
> FAIL Test Summary:
> ComputerSystem - 23_suspend_suspend.py: FAIL
The above tc passed when run manually.
Do you know what caused the guest to fail to start? Does the test
always fail during bulk run?
It sounds like a guest from a previous test isn't being cleaned up
properly. This will need to be fixed.
> =================================================
> XFAIL Test Summary:
> ComputerSystem - 32_start_reboot.py: XFAIL
> ComputerSystem - 33_suspend_reboot.py: XFAIL
> ResourceAllocationFromPool - 05_RAPF_err.py: XFAIL
The above RAFP tc is written to verify that RAFP returns appropriate
error when a non-existing bridge or networkpool is used in defining a
guest.
But, the tc now XFAIL's because it returns a valid RAFP record.
This should be a failure and not an XFAIL. There's no bug number
associated with the failure, so the logic of try_assoc() is incorrectly
returning an XFAIL.
This is due to the use of the cim_define() in the test case.
Before calling the cim_define() we make necessary changes to the XML
configuration to reflect the invalid bridge/networkpool name.
But when we use the cim_define() function we do not have any means where
we can use the invalid networkpool name or bridgename.
cim_define() uses the VSSD and various RASD objects that belong to the
instance of the VirtCIM class that is created. Instead of using
modify_net_name(), the invalid network name should be passed in when the
instance of VirtCIM is initialized.
Hence the DefineSystem() in the cim_define() goes ahead to define a
guest with the valid networkpoolname and RAFP returns a record, which is
against the test case.
I ran the tc for Xen/XenFV and the tc fails there as well.
Can we revert back to the define() [which used virsh to define the
guest], which initially existed in the tc ??
If we use the virsh define, we're testing the virsh define call - the
provider DefineSystem() is not being tested in this case. Wherever
possible, we should be using DefineSystem() so that the provider stack
is tested.
--
Kaitlin Rupert
IBM Linux Technology Center
kaitlin(a)linux.vnet.ibm.com
7:30 p.m.
Kaitlin Rupert wrote:
>> =================================================
>> FAIL Test Summary:
>> ComputerSystem - 23_suspend_suspend.py: FAIL
> The above tc passed when run manually.
Do you know what caused the guest to fail to start? Does the test
always fail during bulk run?
It sounds like a guest from a previous test isn't being cleaned up
properly. This will need to be fixed.
>> =================================================
>> XFAIL Test Summary:
>> ComputerSystem - 32_start_reboot.py: XFAIL
>> ComputerSystem - 33_suspend_reboot.py: XFAIL
>> ResourceAllocationFromPool - 05_RAPF_err.py: XFAIL
> The above RAFP tc is written to verify that RAFP returns appropriate
> error when a non-existing bridge or networkpool is used in defining a
> guest.
> But, the tc now XFAIL's because it returns a valid RAFP record.
This should be a failure and not an XFAIL. There's no bug number
associated with the failure, so the logic of try_assoc() is
incorrectly returning an XFAIL.
Yes it should return FAIL when a bug no is not
specified ( implying that
this is a failure and no bug exist against the association being tried.)
> This is due to the use of the cim_define() in the test case.
> Before calling the cim_define() we make necessary changes to the XML
> configuration to reflect the invalid bridge/networkpool name.
> But when we use the cim_define() function we do not have any means
> where we can use the invalid networkpool name or bridgename.
cim_define() uses the VSSD and various RASD objects that belong to the
instance of the VirtCIM class that is created. Instead of using
modify_net_name(), the invalid network name should be passed in when
the instance of VirtCIM is initialized.
Yes, I agree with you that we should make
use of the Providers supplied
functions, like DefineSystem() as much possible.
I had tried supplying the networkpoolname/bridgename in the VirtXML,
and it works fine till then to get an XML which contains invalid
networkpool/bridgename.
But when we call cim_define() we dont make use of the XML generated till
then.
In cim_define() we make use of VSSD, various RASD and I did not find a
relevant field in NetRASD which could be used for supplying the invalid
name info.
Here is the NetRASD fields.
-Caption
-Description
-InstanceID
-ElementName
-ConfigurationName
-ChangeableType
-ResourceType=10
-OtherResourceType
-ResourceSubType
-PoolID
-ConsumerVisibility
-HostResource
-AllocationUnits
-VirtualQuantity
-Reservation
-Limit
-Weight
-AutomaticAllocation
-AutomaticDeallocation
-Parent
-Connection
-Address
-MappingBehavior
-NetworkType
I tried using ElementName, but was not much help.
Can you suggest how or which of the VSSD, RASD fields could be used to
supply the networkpool/birdge name.
Thanks and Regards,
Deepti.
> Hence the DefineSystem() in the cim_define() goes ahead to define a
> guest with the valid networkpoolname and RAFP returns a record, which
> is against the test case.
> I ran the tc for Xen/XenFV and the tc fails there as well.
> Can we revert back to the define() [which used virsh to define the
> guest], which initially existed in the tc ??
If we use the virsh define, we're testing the virsh define call - the
provider DefineSystem() is not being tested in this case. Wherever
possible, we should be using DefineSystem() so that the provider stack
is tested.
2:04 a.m.
Yes, I agree with you that we should make use of the Providers
supplied
functions, like DefineSystem() as much possible.
I had tried supplying the networkpoolname/bridgename in the VirtXML,
and it works fine till then to get an XML which contains invalid
networkpool/bridgename.
But when we call cim_define() we dont make use of the XML generated till
then.
In cim_define() we make use of VSSD, various RASD and I did not find a
relevant field in NetRASD which could be used for supplying the invalid
name info.
I tried using ElementName, but was not much help.
Can you suggest how or which of the VSSD, RASD fields could be used to
supply the networkpool/birdge name.
The get_nasd_class() function takes a network name. So, the __init__
for the VirtCIM class should take a network name and pass this to the
get_nasd_class() function.
When I replied yesterday, I thought __init__ was already taking the
network name as an argument. Sorry for the confusion there.
--
Kaitlin Rupert
IBM Linux Technology Center
kaitlin(a)linux.vnet.ibm.com
6:48 p.m.
Kaitlin Rupert wrote:
> Yes, I agree with you that we should make use of the Providers
> supplied functions, like DefineSystem() as much possible.
> I had tried supplying the networkpoolname/bridgename in the VirtXML,
> and it works fine till then to get an XML which contains invalid
> networkpool/bridgename.
> But when we call cim_define() we dont make use of the XML generated
> till then.
> In cim_define() we make use of VSSD, various RASD and I did not find
> a relevant field in NetRASD which could be used for supplying the
> invalid name info.
> I tried using ElementName, but was not much help.
> Can you suggest how or which of the VSSD, RASD fields could be used
> to supply the networkpool/birdge name.
>
The get_nasd_class() function takes a network name. So, the __init__
for the VirtCIM class should take a network name and pass this to the
get_nasd_class() function.
When I replied yesterday, I thought __init__ was already taking the
network name as an argument. Sorry for the confusion there.
Ya right, the get_nasd_class() takes the net_name.
1) The only place where the networkname/bridgename can be passed is
through the PoolID, is this correct ?
2) Like the way we supply networkpool info as part of PoolID, how do we
supply the same for Bridge type ?
According to me PoolID='Bridge/virbr0' should work, right ?
Also, I believe the PoolID='Bridge/virbr0' information translates to
the following in the XML ?
<interface type='bridge'>
<mac address='00:11:22:33:44:aa'/>
<source bridge='virbr0'/>
</interface>
I tried using the PoolID='Bridge/bridgewrong' to test the
05_RAPF_err.py tc and it worked for me on KVM.
Using PoolID='Bridge/bridgewrong' the XML from the debug statement
contained the interface type as network as below:
xmlgen.c(640): New UUID
Virt_VirtualSystemManagementService.c(990): System XML:
<domain type='kvm'>
<uuid>5ed4620c-3d04-43b4-995e-36e6da93cf63</uuid>
<name>RAPF_domain</name>
<on_poweroff>destroy</on_poweroff>
<on_crash>destroy</on_crash>
<os>
<type>hvm</type>
<boot dev='hd'/>
</os>
<currentMemory>131072</currentMemory>
<memory>131072</memory>
<vcpu>1</vcpu>
<devices>
*<interface type='network'>
<mac address='00:11:22:33:44:aa'/>
<source network='bridgewrong'/>
</interface>
*<disk type='file' device='disk'>
<source file='/tmp/default-kvm-dimage'/>
<target dev='hda'/>
</disk>
<graphics type='vnc' port='-1'/>
</devices>
</domain>
But for Xen/XenFV , using PoolID='Bridge/bridgewrong' and with the
above mapping of bridgeinfo supplied as part of the PoolID to network in
the XML fails with the following error:
*misc_util.c(72): Connecting to libvirt with uri `xen'
libvir: QEMU error : no network with matching name
Virt_VirtualSystemManagementService.c(771): Failed to define domain
from XML*
The above error thrown by the provider is valid for Xen/XenFV, since
even virsh fails to define a VS when an non-existing networkpool info is
used.
[Note: it allowed the VS to be defined with non-existing bridge]
How and why is it important to map from Bridge to network from the
providers perspective ?
Can't we just retain the information that is supplied through NetRASD
as it is ?
Am, I missing something ? Can you help me proceed with the
implementation of non-existing networkpoolname/bridgename scenario in
05_RAPF_err.py .
Thanks and Regards,
Deepti.
4:50 a.m.
> The get_nasd_class() function takes a network name. So, the
__init__
> for the VirtCIM class should take a network name and pass this to the
> get_nasd_class() function.
>
> When I replied yesterday, I thought __init__ was already taking the
> network name as an argument. Sorry for the confusion there.
Ya right, the get_nasd_class() takes the net_name.
1) The only place where the networkname/bridgename can be passed is
through the PoolID, is this correct ?
2) Like the way we supply networkpool info as part of PoolID, how do we
supply the same for Bridge type ?
According to me PoolID='Bridge/virbr0' should work, right ?
Also, I believe the PoolID='Bridge/virbr0' information translates to
the following in the XML ?
<interface type='bridge'>
<mac address='00:11:22:33:44:aa'/>
<source bridge='virbr0'/>
</interface>
The PoolID is used to pass in the network pool name. The providers
currently don't support creating a guest with a bridge type.
The format for PoolID is "NetworkPool/networkpool_name" - so passing
"Bridge/bridgewrong" isn't the proper format.
I tried using the PoolID='Bridge/bridgewrong' to test the
05_RAPF_err.py tc and it worked for me on KVM.
If you tried to start this guest, you'd get the following error:
type.
libvir: QEMU error : internal error Network 'bridgewrong' not found
But for Xen/XenFV , using PoolID='Bridge/bridgewrong' and
with the
above mapping of bridgeinfo supplied as part of the PoolID to network in
the XML fails with the following error:
*misc_util.c(72): Connecting to libvirt with uri `xen'
libvir: QEMU error : no network with matching name
Virt_VirtualSystemManagementService.c(771): Failed to define domain
from XML*
Dan - do you think this is a check that we should be doing in the
providers? I can see a situation where someone might want to create
template guest - where the its not important if the network pool exists.
It's unfortunate that a precheck is done in the Xen case but not the KVM
case.
The above error thrown by the provider is valid for Xen/XenFV, since
even virsh fails to define a VS when an non-existing networkpool info is
used.
[Note: it allowed the VS to be defined with non-existing bridge]
How and why is it important to map from Bridge to network from the
providers perspective ?
If a network pool is suppled when a guest is defined, libvirt will
handle the appropriate mapping to a bridge. This is why the providers
define guests with the network type.
Can't we just retain the information that is supplied through
NetRASD
as it is ?
Am, I missing something ? Can you help me proceed with the
implementation of non-existing networkpoolname/bridgename scenario in
05_RAPF_err.py .
To use cim_define(), you'll need to remove the bridge related portion of
the test. Only the network scenario is valid.
--
Kaitlin Rupert
IBM Linux Technology Center
kaitlin(a)linux.vnet.ibm.com
8:30 p.m.
Kaitlin Rupert wrote:
>> The get_nasd_class() function takes a network name. So, the
>> __init__ for the VirtCIM class should take a network name and pass
>> this to the get_nasd_class() function.
>>
>> When I replied yesterday, I thought __init__ was already taking the
>> network name as an argument. Sorry for the confusion there.
>
> Ya right, the get_nasd_class() takes the net_name.
> 1) The only place where the networkname/bridgename can be passed is
> through the PoolID, is this correct ?
> 2) Like the way we supply networkpool info as part of PoolID, how do
> we supply the same for Bridge type ?
> According to me PoolID='Bridge/virbr0' should work, right ?
> Also, I believe the PoolID='Bridge/virbr0' information translates
> to the following in the XML ?
> <interface type='bridge'>
> <mac address='00:11:22:33:44:aa'/>
> <source bridge='virbr0'/>
> </interface>
The PoolID is used to pass in the network pool name. The providers
currently don't support creating a guest with a bridge type.
The format for PoolID is "NetworkPool/networkpool_name" - so passing
"Bridge/bridgewrong" isn't the proper format.
>
> I tried using the PoolID='Bridge/bridgewrong' to test the
> 05_RAPF_err.py tc and it worked for me on KVM.
If you tried to start this guest, you'd get the following error:
type.
libvir: QEMU error : internal error Network 'bridgewrong' not found
> But for Xen/XenFV , using PoolID='Bridge/bridgewrong' and with the
> above mapping of bridgeinfo supplied as part of the PoolID to network
> in the XML fails with the following error:
>
> *misc_util.c(72): Connecting to libvirt with uri `xen'
> libvir: QEMU error : no network with matching name
> Virt_VirtualSystemManagementService.c(771): Failed to define domain
> from XML*
Dan - do you think this is a check that we should be doing in the
providers? I can see a situation where someone might want to create
template guest - where the its not important if the network pool exists.
It's unfortunate that a precheck is done in the Xen case but not the
KVM case.
>
> The above error thrown by the provider is valid for Xen/XenFV, since
> even virsh fails to define a VS when an non-existing networkpool info
> is used.
> [Note: it allowed the VS to be defined with non-existing bridge]
> How and why is it important to map from Bridge to network from the
> providers perspective ?
If a network pool is suppled when a guest is defined, libvirt will
handle the appropriate mapping to a bridge. This is why the providers
define guests with the network type.
> Can't we just retain the information that is supplied through
> NetRASD as it is ?
> Am, I missing something ? Can you help me proceed with the
> implementation of non-existing networkpoolname/bridgename scenario in
> 05_RAPF_err.py .
To use cim_define(), you'll need to remove the bridge related portion
of the test. Only the network scenario is valid.
I can retain the network part of
the tc, but I remember we were of the
opinion for keeping some of the test case to use virsh so that the
providers is able to handle the information for the VS created outside
using VSMS.
Thanks and Regards,
Deepti.
11:17 p.m.
>> Can't we just retain the information that is supplied
through
>> NetRASD as it is ?
>> Am, I missing something ? Can you help me proceed with the
>> implementation of non-existing networkpoolname/bridgename scenario in
>> 05_RAPF_err.py .
>
> To use cim_define(), you'll need to remove the bridge related portion
> of the test. Only the network scenario is valid.
I can retain the network part of the tc, but I remember we were of the
opinion for keeping some of the test case to use virsh so that the
providers is able to handle the information for the VS created outside
using VSMS.
Yes, I agree that some tests should retain guests defined by virsh. But
having guests defined by virsh is far less important. Really, we've
been using virsh as a crutch. I don't think we need very many test
cases to retain virsh defined guests.
The purpose of the test suite is to test the providers, not to test
virsh. So the fewer tests that rely on using virsh to define guests we
have, the better the test suite is at exercising the providers.
--
Kaitlin Rupert
IBM Linux Technology Center
kaitlin(a)linux.vnet.ibm.com
11:34 p.m.
Kaitlin Rupert wrote:
>>> Can't we just retain the information that is
supplied through
>>> NetRASD as it is ?
>>> Am, I missing something ? Can you help me proceed with the
>>> implementation of non-existing networkpoolname/bridgename scenario
>>> in 05_RAPF_err.py .
>>
>> To use cim_define(), you'll need to remove the bridge related
>> portion of the test. Only the network scenario is valid.
> I can retain the network part of the tc, but I remember we were of
> the opinion for keeping some of the test case to use virsh so that
> the providers is able to handle the information for the VS created
> outside using VSMS.
Yes, I agree that some tests should retain guests defined by virsh.
But having guests defined by virsh is far less important. Really,
we've been using virsh as a crutch. I don't think we need very many
test cases to retain virsh defined guests.
The purpose of the test suite is to test the providers, not to test
virsh. So the fewer tests that rely on using virsh to define guests
we have, the better the test suite is at exercising the providers.
Yes, I agree. I will keep the cim_start() for network type and update
the tc.
Thanks and Regards,
Deepti.
11:42 p.m.
Deepti B Kalakeri wrote:
Kaitlin Rupert wrote:
>>>> Can't we just retain the information that is supplied through
>>>> NetRASD as it is ?
>>>> Am, I missing something ? Can you help me proceed with the
>>>> implementation of non-existing networkpoolname/bridgename scenario
>>>> in 05_RAPF_err.py .
>>>
>>> To use cim_define(), you'll need to remove the bridge related
>>> portion of the test. Only the network scenario is valid.
>> I can retain the network part of the tc, but I remember we were of
>> the opinion for keeping some of the test case to use virsh so that
>> the providers is able to handle the information for the VS created
>> outside using VSMS.
>
> Yes, I agree that some tests should retain guests defined by virsh.
> But having guests defined by virsh is far less important. Really,
> we've been using virsh as a crutch. I don't think we need very many
> test cases to retain virsh defined guests.
>
> The purpose of the test suite is to test the providers, not to test
> virsh. So the fewer tests that rely on using virsh to define guests
> we have, the better the test suite is at exercising the providers.
>
Yes, I agree. I will keep the cim_start() for network type and update
the tc.
Great, thanks!
--
Kaitlin Rupert
IBM Linux Technology Center
kaitlin(a)linux.vnet.ibm.com
5836
days inactive
5841
days old
10 comments
2 participants
participants (2)
-
Deepti B Kalakeri -
Kaitlin Rupert