IBM Power Virtualization Center (PowerVC) provides a simple user interface for managing your virtualized IBM POWER systems. In the 1.2.1 release of PowerVC, that management support extends to POWER8 processor-based Linux scale-out servers running the IBM PowerKVM hypervisor.
As you might expect, the technology stack between PowerKVM and IBM PowerVM are quite different. In PowerVM, the administrator virtualizes hardware on a VIOS LPAR and initializes the Shared Ethernet Adapter via the HMC or IVM console. For more information about this, see the Introduction to PowerVC Networking for HMC.
For PowerKVM systems, the technology stack is based on Open Source technologies (based on Openstack’s neutron service). For networking purposes, PowerVC uses Open vSwitch. We feel that this offers the user the most features and capabilities and sets up a strong foundation for future technologies.
Open vSwitch is an open source, virtual Ethernet switch that can be backed by a set of physical Ethernet ports. It differs from a standard Linux bridge because it is actually an Ethernet switch – which can reduce the traffic that each virtual machine sees and therefore improves performance. It also provides better support for bonding physical adapters, a more approachable CLI interface, and good integration with existing network tools. Open vSwitch is also used to enable the creation of automated network infrastructure for virtualized environments by automating VLAN deployment on the host server.
Configuration out of the box is quite simple. When registering a host with PowerVC, the product will automatically create a new virtual switch named ‘default’. It will then attempt to identify the physical adapter that traffic is currently flowing through to the management node, and add it to the virtual switch. If for some reason the connection is lost during this process, PowerVC will roll back the configuration to its original state.
For some environments, this means that networking will work directly out of the box. Simply register the system and your Virtual switch is primed. For others, especially those requiring separate physical networks, the users will need to modify the components of the virtual switch.
This can be done by going to the Hosts page in PowerVC. Once there, edit the virtual switch and select the appropriate components.
The user can select multiple adapters to be part of the virtual switch. If they do, a bonded NIC will be created. The bonded NIC will be a Server Load Balancing bond – therefore requiring no changes on the physical switch itself (like LACP would). In future versions, we are evaluating adding more bonding types.
If the users do not like the behavior of adding the NIC to the default virtual switch, they can make the following addition to the /etc/nova/nova.conf file on their PowerVC server, then restart the PowerVC services (/opt/ibm/powervc/bin/powervc-services restart):
enable_kvm_ovs_auto_config = False
Afterward, the default behavior will simply be to create the default virtual switch, but the user will need to manually add physical components to the switch. Without physical components being added to the virtual switch, Ethernet traffic will not flow to the broader network.
Adding and Removing out of band virtual switches
PowerVC does not yet support adding or removing virtual switches from the user interface. However, administrators can go to their PowerKVM systems and directly add a virtual switch to the system.
This can be done with the following commands:
ovs-vsctl add-br <vswitch name>
Once the virtual switch is created, it should show up in the PowerVC user interface with a refresh of the Hosts page. Ethernet ports can then be added to the virtual switch.
Similarly, to remove a virtual switch, run the following command:
ovs-vsctl del-br <vswitch name>
Though the user may also need to remove the corresponding ifcfg file that describes the virtual switch on system start up, typically found in /etc/sysconfig/network-scripts/.
What happens when PowerVC modifies a virtual switch?
When PowerVC modifies a virtual switch, it follows this general flow:
- Determine the current state of the system.
Validate that the state supports the requested change.
- Warn the user if needed.
Break the request into several operations. Examples include:
- Write ifcfg file changes
- Add/remove ports to virtual switches
- Execute each operation.
Validate that the host can still talk to the PowerVC node.
- If not, roll back all of the changes.
- Otherwise, save the applied changes.
The last item is very important because the PowerVC code will attempt to ensure that any and all changes that are requested do not break communication with the management node. If they do break communication, the changes are rolled back and the original state is preserved. Otherwise, the applied changes are saved.
PowerVC builds all of its virtual switch data from the configuration of the PowerKVM system itself. It does not store local data that can get out of sync with the system.
PowerVC exploits key functionality of Openstack’s network service and distributed open source multilayer Open vSwitch for managing networking in a PowerKVM environment. Via its user friendly console, PowerVC enables the user to do extensive network configuration, like editing virtual switches, and deploying, managing, and deleting VMs automatically.
Visit ibm.com today to learn more about PowerVC and learn how it can help you!