Deepti B. Kalakeri wrote:
# HG changeset patch
# User Deepti B. Kalakeri <deeptik(a)linux.vnet.ibm.com>
# Date 1213711825 25200
# Node ID 73d199833bce1a21f374a1c8c95885a749e955cc
# Parent 9700e5130a511e8a5457ba3033eb57d7b0b6a656
[TEST] Fixed the tc 05_RAPF_err.py.
1) Added support for verifying the exception when an invalid network name is passed.
2) Modified get_unique_bridge() to now return non-existing bridgename/networkpoolnmae.
3) Modified the code to occupy 80 columns only.
4) Removed the global declaration of the virt and server and passed them as parameters to
fn instead.
This tc passed on KVM with latest sources and libvirt-cim rpm on F9.
This tc fails for Xen/XenFV when an invalid networkpoolname.
The libvirt does not support definining the Xen/XenFV guest with invalid network name.
This test is creating invalid guests - you won't be able to start the
KVM guest, even though the define succeeds. It's good to have a test to
make sure we handle broken guests properly.
Since this isn't supported for Xen/XenFV - this test should skip instead
of failine.
It'd also be good to have a test where we create a valid guest with a
network device that isn't part of a pool. For Xen/XenFV guests, this
can be done using an ethernet interface. It should be possible to do
something similar with KVM and the user interface type, but I've not
tried this. I'll add this test case idea to the wiki to keep track of it.
Signed-off-by: Deepti B. Kalakeri <deeptik(a)linux.vnet.ibm.com>
diff -r 9700e5130a51 -r 73d199833bce
suites/libvirt-cim/cimtest/ResourceAllocationFromPool/05_RAPF_err.py
vsxml_info.set_net_name(int_name)
-# Assigning the bridge that does not belong to any networkpool.
- vsxml_info.set_bridge_name(bridge_name)
+ if vsxml_net_type != 'bridge' and nettype == 'bridge':
+ vsxml_info.set_nettype(nettype)
+ in_string = 'network="%s"' %int_name
+ out_string = 'bridge="%s"' %int_name
+ vsxml_replace = (vsxml_info.xml_string.replace(in_string, out_string))
+ vsxml_info.xml_string = vsxml_replace
Instead of hacking the xml_string directly, could something like
set_interface_details() be modified to change the existing interface?
Or maybe a new function for this?
Another option would be to allow the KVMXML (etc) init call to take a
network type. That way, you could create an XML of whatever interface
type you'd like (instead of modifying it afterwards).
@do_main(platform_sup)
def main():
- global virt, server
options = main.options
server = options.ip
virt = options.virt
destroy_and_undefine_all(server)
+ in_list = [ 'bridge', 'network' ]
- status, vsxml = setup_env()
- if status != PASS:
- logger.error("Failed to setup the domain")
- return status
+ for interface in in_list:
+ status, vsxml = setup_env(server, virt, interface)
+ if status != PASS:
You'll need to undefine the guest here. Even though virsh is returning
an error, the guest is being defined.
+ logger.error("Failed to setup the domain")
+ return status
--
Kaitlin Rupert
IBM Linux Technology Center
kaitlin(a)linux.vnet.ibm.com