[PATCH] [TEST] Adding 05_RAPF_err.py to verify RAPF

# HG changeset patch # User Deepti B. Kalakeri <deeptik@linux.vnet.ibm.com> # Date 1207303009 -19800 # Node ID 0142551c8d3cf5f2a3bbdfe835d69c3880be395a # Parent dce42f09c9c60c59e15db48882bc8fb68301238f [TEST] Adding 05_RAPF_err.py to verify RAPF. The test : creates a guest with a network device that is not part of a known pool. Then call ResourceAllocatedFromPool with the reference to that device. Verifies for the error. Signed-off-by: Deepti B. Kalakeri <deeptik@linux.vnet.ibm.com> diff -r dce42f09c9c6 -r 0142551c8d3c suites/libvirt-cim/cimtest/ResourceAllocationFromPool/05_RAPF_err.py --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/suites/libvirt-cim/cimtest/ResourceAllocationFromPool/05_RAPF_err.py Fri Apr 04 15:26:49 2008 +0530 @@ -0,0 +1,204 @@ +#!/usr/bin/python +# +# Copyright 2008 IBM Corp. +# +# Authors: +# Deepti B. Kalakeri <deeptik@linux.vnet.ibm.com> +# +# This library is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public +# License as published by the Free Software Foundation; either +# version 2.1 of the License, or (at your option) any later version. +# +# This library is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU +# General Public License for more details. +# +# You should have received a copy of the GNU General Public +# License along with this library; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA +# +# This tc is used to verify the that the +# ResourceAllocationFromPool asscoiation returns error +# when guest is associated to a non-existing virtual network pool. +# +# The does the following: +# 1) creates a guest with a network device that is not part of a known pool, +# 2) call ResourceAllocatedFromPool with the reference to that device. +# 3) Verifies for the following error: +# +# Command: +# -------- +# wbemcli ain -ac KVM_ResourceAllocationFromPool +# 'http://localhost:5988/root/virt:KVM_NetResourceAllocationSettingData. +# InstanceID="test-kvm/24:42:53:21:52:45"' +# +# +# Output: +# ------- +# error no : CIM_ERR_FAILED +# error desc : "Unable to determine pool of `test-kvm/24:42:53:21:52:45';" +# +# Date : 04-04-2008 +# +import sys +import pywbem +from VirtLib import live +from XenKvmLib import assoc, enumclass +from XenKvmLib.common_util import try_assoc +from XenKvmLib.test_doms import destroy_and_undefine_all +from CimTest import Globals +from CimTest.Globals import logger, CIM_ERROR_ENUMERATE +from CimTest.ReturnCodes import PASS, FAIL +from CimTest.Globals import do_main, platform_sup +from XenKvmLib.vxml import get_class +from XenKvmLib.classes import get_typed_class + +test_dom = "RAPF_domain" +test_mac = "00:11:22:33:44:aa" +test_vcpus = 1 + + +def check_bridge_name(bridgename): + bridge_list = live.available_bridges(server) + vbr = None + if bridgename in bridge_list: + import random + vbr = bridgename + str(random.randint(1, 100)) + if vbr in bridge_list: + logger.error('Need to give different bridge name since it already exists') + return None + else: + vbr = bridgename + return vbr + +def setup_env(): + vsxml = None + if virt == "Xen": + test_disk = "xvda" + else: + test_disk = "hda" + + virt_xml = get_class(virt) + vsxml = virt_xml(test_dom, vcpus = test_vcpus, mac = test_mac, disk = test_disk) + if virt != 'XenFV': + bridge = vsxml.set_vbridge(server) + +# Get a bridge name that is not used by any of the virtual network pool on the machine. + bridge_name = check_bridge_name('invalid-bridge') + if bridge_name == None: + logger.error("Failed to get an invalid bridge name") + return FAIL, vsxml +# Assigning the bridge that does not belong to any networkpool. + vsxml.set_bridge_name(bridge_name) + + ret = vsxml.define(server) + if not ret: + Globals.logger.error("Failed to define the dom: %s", test_dom) + return FAIL, vsxml + + return PASS, vsxml + +def get_inst_from_list(classname, rasd_list, filter_name, exp_val): + status = PASS + ret = FAIL + inst = [] + + for rec in rasd_list: + record = rec[filter_name] + if exp_val in record: + inst.append(rec) + ret = PASS + + if ret != PASS: + logger.error("%s with %s was not returned" % (classname, exp_val)) + vsxml.undefine(server) + status = FAIL + + return status, inst + +def get_netrasd_instid(classname): + rasd_list = [] + status = PASS + try: + rasd_list = enumclass.enumerate_inst(server, classname, virt) + if len(rasd_list) < 1: + logger.error("%s returned %i instances, excepted atleast 1 instance", classname, + len(rasd_list)) + status = FAIL + except Exception, detail: + logger.error(CIM_ERROR_ENUMERATE, classname) + logger.error("Exception: %s", detail) + status = FAIL + + if status != PASS: + return status, rasd_list + + # Get the RASD info related to the domain "ONLY". + # We should get ONLY one record. + rasd_info = [] + status, rasd_info = get_inst_from_list(classname, rasd_list, "InstanceID", test_dom) + + return status, rasd_info + +def verify_rapf_err(): + status = PASS + try: + + classname = get_typed_class(virt, 'NetResourceAllocationSettingData') + status, net_rasd_list = get_netrasd_instid(classname) + if status != PASS or len(net_rasd_list) == 0: + return status + if len(net_rasd_list) != 1: + logger.error("%s returned %i instances, excepted atleast 1 instance", classname, + len(net_rasd_list)) + return FAIL + + + conn = assoc.myWBEMConnection('http://%s' % server, + (Globals.CIM_USER, + Globals.CIM_PASS), + Globals.CIM_NS) + assoc_classname = get_typed_class(virt, "ResourceAllocationFromPool") + classname = net_rasd_list[0].classname + instid = net_rasd_list[0]['InstanceID'] + keys = { "InstanceID" : instid } + expr_values = { + 'rapf_err' : { + 'desc' : "Unable to determine pool of `%s'" %instid, + 'rc' : pywbem.CIM_ERR_FAILED + } + } + status = try_assoc(conn, classname, assoc_classname, keys, field_name="InstanceID", + expr_values=expr_values['rapf_err'], bug_no="") + + except Exception, detail: + logger.error("Exception: %s", detail) + status = FAIL + + return status + +@do_main(platform_sup) +def main(): + global virt, vsxml, server + Globals.log_param() + options = main.options + server = options.ip + virt = options.virt + destroy_and_undefine_all(server) + + status, vsxml = setup_env() + if status != PASS: + logger.error("Failed to setup the domain") + return status + + ret = verify_rapf_err() + if ret: + logger.error("------FAILED: to verify the RAFP.------") + status = ret + + vsxml.undefine(server) + return status +if __name__ == "__main__": + sys.exit(main())

DK> +def check_bridge_name(bridgename): DK> + bridge_list = live.available_bridges(server) DK> + vbr = None DK> + if bridgename in bridge_list: DK> + import random DK> + vbr = bridgename + str(random.randint(1, 100)) DK> + if vbr in bridge_list: DK> + logger.error('Need to give different bridge name since it already exists') DK> + return None DK> + else: DK> + vbr = bridgename DK> + return vbr I think this would make a lot more sense as: def get_unique_bridge(): bridge = "invalid-bridge" while bridge not in live.available_bridges(): bridge += str(random.randint(1,100)) return bridge DK> + if virt != 'XenFV': DK> + bridge = vsxml.set_vbridge(server) Can you explain why this special case exists? -- Dan Smith IBM Linux Technology Center Open Hypervisor Team email: danms@us.ibm.com

Dan Smith wrote:
DK> +def check_bridge_name(bridgename): DK> + bridge_list = live.available_bridges(server) DK> + vbr = None DK> + if bridgename in bridge_list: DK> + import random DK> + vbr = bridgename + str(random.randint(1, 100)) DK> + if vbr in bridge_list: DK> + logger.error('Need to give different bridge name since it already exists') DK> + return None DK> + else: DK> + vbr = bridgename DK> + return vbr
I think this would make a lot more sense as:
def get_unique_bridge(): bridge = "invalid-bridge"
while bridge not in live.available_bridges(): bridge += str(random.randint(1,100))
return bridge
Ok , will modify this.
DK> + if virt != 'XenFV': DK> + bridge = vsxml.set_vbridge(server)
Can you explain why this special case exists?
The network information for the XenFV is getting assigned by default. The def _devices(): section of the XenFV is calling the self.set_bridge(CIM_IP) and hence the bridge information is getting assigned by default. While this is not the case with the Xen and KVM.
------------------------------------------------------------------------
_______________________________________________ Libvirt-cim mailing list Libvirt-cim@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-cim

Deepti B Kalakeri wrote:
Dan Smith wrote:
DK> +def check_bridge_name(bridgename): DK> + bridge_list = live.available_bridges(server) DK> + vbr = None DK> + if bridgename in bridge_list: DK> + import random DK> + vbr = bridgename + str(random.randint(1, 100)) DK> + if vbr in bridge_list: DK> + logger.error('Need to give different bridge name since it already exists') DK> + return None DK> + else: DK> + vbr = bridgename DK> + return vbr
I think this would make a lot more sense as:
def get_unique_bridge(): bridge = "invalid-bridge" while bridge not in live.available_bridges(): bridge += str(random.randint(1,100)) return bridge
Ok , will modify this.
DK> + if virt != 'XenFV': DK> + bridge = vsxml.set_vbridge(server)
Can you explain why this special case exists?
The network information for the XenFV is getting assigned by default. The def _devices(): section of the XenFV is calling the
self.set_bridge(CIM_IP) and hence the bridge information is getting assigned by default. While this is not the case with the Xen and KVM.
KVM also calls set_bridge() in the _devices() call. Xen does not, but the _devices() call for Xen sets the interface as an ethernet type. So there's no need to set a bridge for the Xen case. -- Kaitlin Rupert IBM Linux Technology Center kaitlin@linux.vnet.ibm.com

Deepti B Kalakeri wrote:
Dan Smith wrote:
DK> +def check_bridge_name(bridgename): DK> + bridge_list = live.available_bridges(server) DK> + vbr = None DK> + if bridgename in bridge_list: DK> + import random DK> + vbr = bridgename + str(random.randint(1, 100)) DK> + if vbr in bridge_list: DK> + logger.error('Need to give different bridge name since it already exists') DK> + return None DK> + else: DK> + vbr = bridgename DK> + return vbr
I think this would make a lot more sense as:
def get_unique_bridge(): bridge = "invalid-bridge" while bridge not in live.available_bridges(): bridge += str(random.randint(1,100)) return bridge
Ok , will modify this.
DK> + if virt != 'XenFV': DK> + bridge = vsxml.set_vbridge(server)
Can you explain why this special case exists?
The network information for the XenFV is getting assigned by default. The def _devices(): section of the XenFV is calling the
self.set_bridge(CIM_IP) and hence the bridge information is getting assigned by default. While this is not the case with the Xen and KVM.
KVM also calls set_bridge() in the _devices() call.
Xen does not, but the _devices() call for Xen sets the interface as an ethernet type. So there's no need to set a bridge for the Xen case. Wrt to the tc when working with NetRASD requires the domain to be created with interface type as bridge. NetRASD lists the domains which are created with bridge as the network type. Please correct me if I am wrong. I suggest we keep the default network type for all the three Virtual types to be bridge and the give another function which allows to add network type other than bridge to
Kaitlin Rupert wrote: the domain when required

Ok , will modify this.
DK> + if virt != 'XenFV': DK> + bridge = vsxml.set_vbridge(server)
Can you explain why this special case exists?
The network information for the XenFV is getting assigned by default. The def _devices(): section of the XenFV is calling the
self.set_bridge(CIM_IP) and hence the bridge information is getting assigned by default. While this is not the case with the Xen and KVM.
KVM also calls set_bridge() in the _devices() call.
Xen does not, but the _devices() call for Xen sets the interface as an ethernet type. So there's no need to set a bridge for the Xen case. Wrt to the tc when working with NetRASD requires the domain to be created with interface type as bridge. NetRASD lists the domains which are created with bridge as the network type. Please correct me if I am wrong.
You'll only get a NetRASD instance if the guest has an interface that is tied to a virtual network. That is - if the guest's bridge belongs to a defined virtual network.
I suggest we keep the default network type for all the three Virtual types to be bridge and the give another function which allows to add network type other than bridge to the domain when required
The original Xen XML used an ethernet style network as the default. Can you verify which (if any) test cases will be affected if we change Xen to use a bridge style network as the default? In general, I'd like to see the default XML for all three types be as similar as possible (where it makes sense). So I think this is a sound idea. -- Kaitlin Rupert IBM Linux Technology Center kaitlin@linux.vnet.ibm.com

Kaitlin Rupert wrote:
Ok , will modify this.
DK> + if virt != 'XenFV': DK> + bridge = vsxml.set_vbridge(server)
Can you explain why this special case exists?
The network information for the XenFV is getting assigned by default. The def _devices(): section of the XenFV is calling the
self.set_bridge(CIM_IP) and hence the bridge information is getting assigned by default. While this is not the case with the Xen and KVM.
KVM also calls set_bridge() in the _devices() call.
Xen does not, but the _devices() call for Xen sets the interface as an ethernet type. So there's no need to set a bridge for the Xen case. Wrt to the tc when working with NetRASD requires the domain to be created with interface type as bridge. NetRASD lists the domains which are created with bridge as the network type. Please correct me if I am wrong.
You'll only get a NetRASD instance if the guest has an interface that is tied to a virtual network. That is - if the guest's bridge belongs to a defined virtual network.
I suggest we keep the default network type for all the three Virtual types to be bridge and the give another function which allows to add network type other than bridge to the domain when required
The original Xen XML used an ethernet style network as the default. Can you verify which (if any) test cases will be affected if we change Xen to use a bridge style network as the default?
In general, I'd like to see the default XML for all three types be as similar as possible (where it makes sense). So I think this is a sound idea.
I need to verify this.

The original Xen XML used an ethernet style network as the default. Can you verify which (if any) test cases will be affected if we change Xen to use a bridge style network as the default?
In general, I'd like to see the default XML for all three types be as similar as possible (where it makes sense). So I think this is a sound idea.
I need to verify this.
I would check out Dan's recent Network related patchset. If you specify "network" as the network type and the network pool you wish to use, it looks like libvirt will determine the appropriate settings (bridge, etc) for that pool. So, it seems like switching all 3 platforms to network instead of bridge will be the better way to go. -- Kaitlin Rupert IBM Linux Technology Center kaitlin@linux.vnet.ibm.com
participants (4)
-
Dan Smith
-
Deepti B Kalakeri
-
Deepti B. Kalakeri
-
Kaitlin Rupert