Adding PowerVM hosting capabilities
Now that you have seen how virtualization in modeled in System z and x86 you will finally start working on the primary objective of this tutorial: being able to model virtualization scenarios that include PowerVM.
There is one way that already works: since the Power Server doesn't enforce any constraint regarding the number of operating systems that it directly hosts you could just add a number of AIX units to a single Power Server. If you use the customized Linux unit that you changed to allow deployment in System z you can also use it in the same way. This possibility could be seen as inherent support for the built-in PowerVM hypervisor in Power servers, but if you try to do the same with a x86 server, which doesn't have an integrated hypervisor, the same lack of constraint exists.
Figure 31. Directly hosting multiple operating systems
This way of doing things can actually be useful if your goal is to produce a quick diagram (as in Figure 31), more than an actual model that ensures consistency and checks for capabilities and requirements. For that you will need to implement some sort of support for PowerVM, modeled after what already exists for x86 and System z. In this tutorial you will use concepts from both:
- You will initially not use Virtual NIC and Disk definitions, so here you will follow the System z model.
- You will use a Virtual Image, which is closer aligned with the VMware example.
Create a new topology named powervm_topology and add the base stack: an LDAP server, an AIX instance and a Power server just like you did in the section about modeling physical deployments. You will only host the LDAP server in the AIX instance this time since you will need to do some changes first before deploying the AIX unit. Figure 32 shows the topology up to this point.
Figure 32. Initial topology
Take a look at the Virtualization palette category. Notice that there are "container" units for VMware, Xen, and z/VM, and they are fully realized (they have both a conceptual unit and a concrete unit that realizes the conceptual one). There is also a generic-looking section that is mostly just conceptual and doesn't mention any specific technology. This is what you will use. These templates (Figure 33) use the base, technology-independent units and capabilities. This makes them ideal building blocks for the goal of creating PowerVM-specific units.
Figure 33. The Virtualization templates palette
- Drag and drop a conceptual Virtual Image into the diagram. Notice that what would be warnings in a concrete unit are presented as information in a conceptual one.
- Now look at the Requirements of this conceptual unit. This unit can have a server as a member (and only one, as can be seen by the constraint), and can optionally host any number of units, of any kind. More relevant though is the hosting requirement: it needs a (generic) hypervisor.
Figure 34. Virtual Image requirements
In terms of the Capabilities, you can see that this unit implements a Virtual Image and a Virtual Server Definition. The names of the capabilities are sometimes linked with information that hasn't yet been provided, which is why the first capability appears as no imageId. Looking at the Type: information shows the capabilities that are referenced, as Figure 35 shows.
Figure 35. Virtual Image capabilities
Your next step will be to create a concrete unit that can be used to model PowerVM LPARs.
- Deselect the Conceptual check mark from the Virtual Image
Properties in the General tab, and add a Stereotype named
PowerVM LPAR. This stereotype will allow you to quickly see that this concrete unit is a specific kind of Virtual Image.
Figure 36. Adding stereotypes
- Now, make the following changes:
- Delete the AnyMember requirement. Not removing it would not make much of a difference but it will make our unit more in line with the other specialized virtual images.
- Change the Image id to PowerVM LPAR. The Image id field is also in the Capabilities tab.
- Select the field named no imageId and change the appropriate field in the content area to the right.
- To make this unit reusable, you will now add it to the palette:
- Right-click the unit and select Add to Palette.
- Give it a name (
PowerVM LPAR) and an icon
(Figure 37) shows that the System z LPAR icon was selected), and you will find a new entry in the Local Extensions palette category.
Figure 37. Adding a custom unit to the palette
Your next step is to host the new PowerVM LPAR unit in the Power Server, but if you try to you will not be allowed. This is because the LPAR unit needs to be hosted in a server with an hypervisor and by default the Power Server unit in Rational Software Architect doesn't have one. In other words, the PowerVM LPAR has a hosting requirement of type virtualization.Hypervisor, and the Power Server unit does not provide this capability.
To fix this create you will need to create another custom unit: a Power Server with a hypervisor capabilities. You could alternatively create a PowerVM unit to be deployed in a Power Server unit, like the VMware ESX scenario, but the option of adding hypervisor functionality directly in the server reflects the fact that in Power Systems the hypervisor is not an independent software product.
- Select the Power Server unit, go to the Capabilities tab, click the Add Capability... icon. In the pop-up window that appeared choose Virtualization.Hypervisor (Figure 38).
Figure 38. Adding hypervisor capability
- You should also add a PowerVM Server stereotype. The designation isn't strictly correct, but it is short enough to be useful for the purpose of this tutorial. Add this server to the palette by following the same steps as above. Figure 39 shows the workspace after these modifications.
You can now host the PowerVM LPAR in the PowerVM Server.
Figure 39. Hosting the LPAR in the PowerVM server
Your next step is to drop a Power Server into the diagram and make it a member of the PowerVM LPAR. This server will be the one hosting your AIX instance. This concept is the same as the one previously explained and allows for a much easier way to model transformation scenarios, because existing physical servers can be wrapped inside an LPAR.
- Create a hosting link between the AIX unit and this Power Server.
The topology, shown in Figure 40, is now complete and without any warnings
Figure 40. Final topology with all hosting links in place
The concepts used are similar to the x86 and System z examples, namely in the use of three separate layers:
- A physical server that will host the different images (the PowerVM Server)
- A virtual image that represents the partitioning ability of the host (the PowerVM LPAR)
- A virtual server that is a member of the virtual image and provides hosting capabilities (the Power Server inside the LPAR)
The work done in this section is sufficient to model the core aspects of virtualization with PowerVM. The next section will add the ability to model more detail, namely virtual resources, such as disks and Ethernet cards.