Re: [Libvirt-cim] [PATCH] [TEST] Adding set_interface_details() fn to the vxml.py
+ def set_interface_details(self, devices, net_mac, net_type, req_net_type,
virt_type):
+ if net_type != req_net_type:
+ interface = self.add_sub_node(devices, 'interface',
type=req_net_type)
+ else:
+ interface = self.add_sub_node(devices, 'interface', type=net_type)
I'm not sure I understand the need for two net_type parameters here. No
matter what the value of net_type is, you're always setting the value of
the interface to req_net_type.
In the case of the RAFP test, the test was assuming that all guests had
a network device that belonged to a specific pool. So for that test
case, creating a guest with an ethernet interface would not be valid.
However, you could have situations where you'd want to verify that the
providers are properly managing a guest that doesn't have a network
type. One such example would be to verify that adding a new ethernet
resource to a Xen guest with an ethernet interface is successful. Even
though we don't create guests with ethernet devices, we should still be
able to manage them.
So, I like the idea of being able to specify the network type. I think
the req_net_type parameter is unnecessary here.
+ self.add_sub_node(interface, 'mac',
address=net_mac)
+ if req_net_type == 'bridge':
+ self._set_vbridge(CIM_IP, virt_type)
+ elif req_net_type == 'network':
+ self.set_vnetwork(interface, virt_type)
+ elif req_net_type == 'ethernet':
+ pass
You'll also want to support the "user" network type for KVM since
NetworkPort/03_user_netport.py uses it.
The user network type is only valid for KVM, so you wouldn't want to be
able to create Xen guests of this type.
+ else:
+ logger.error("%s is not a valid network type", net_type)
+ sys.exit(1)
--
Kaitlin Rupert
IBM Linux Technology Center
kaitlin(a)linux.vnet.ibm.com