KVM on Pegasus Test Run Summary for Sep 10 2008 [ Current Source]
================================================= 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.
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.
================================================= 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@linux.vnet.ibm.com
================================================= 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
Kaitlin Rupert wrote: 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.
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@linux.vnet.ibm.com
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.
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@linux.vnet.ibm.com
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
Kaitlin Rupert wrote: providers is able to handle the information for the VS created outside using VSMS. Thanks and Regards, Deepti.
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@linux.vnet.ibm.com
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.
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@linux.vnet.ibm.com
participants (2)
-
Deepti B Kalakeri -
Kaitlin Rupert