IBM PowerVM deployment modeling features for virtualization

How to customize the Rational Software Architect topology editor

This tutorial shows how to use IBM® Rational® Software Architect customization abilities to model IBM® PowerVM™ topologies. It walks you through the steps for adding new units, with new capabilities and requirements, and shows how to leverage existing building blocks to add a new virtualization layer. It also describes the existing support for x86 and IBM® System z® virtualization modeling through a step-by-step approach that explains the underlying concepts used and how to apply them in building the new PowerVM model.

Before you start

IBM® Rational® Software Architect is a powerful tool for software development, but the capabilities are not limited to that specific area. With its complete UML support and overall modelling abilities, it can be used in quite flexible ways:

  • Free-form diagramming: The plethora of diagram options provides a complete foundation for free-form diagrams, as they are often used in non-software development scenarios. An IT architecture overview can easily be made by using a Deployment or Component model or even by mixing concepts from different models.
  • Method artifacts: When following a specific methodology (Rational Unified Process or OpenUP, for example) there is often the need to create models and diagrams. Rational Software Architect can be used to good effect in producing them, either by itself or by using specific plug-ins that streamline the process and provide helpful templates.
  • Modeling deployment topologies: This is a specific ability that recent versions make available and one that is different from the UML deployment model.

This tutorial focuses on the last point: deployment topologies. This feature can be used in many different ways. As an example, you could put aside all of the niceties regarding constraints, requirements, and capabilities and simply use it as another form of diagramming. This is true for most parts of Rational Software Architect, in that there is a superficial use that can be immediately productive and a more involved one that takes more time to learn but that has an even higher potential for productivity.

The deployment topologies are not UML (although they will use UML links if they are present and are integrated with existing UML diagrams), and they can represent a wide variety of computer systems in different levels of abstraction. It's quite intuitive, because it doesn't require the level of conceptual understanding that UML does. It uses well-known terms for well-known relationships among software, hardware, and other IT components. By default, Rational Software Architect comes with templates that cover many different software packages, hardware models, operating systems, and many other different units in different domains. But equally important, Rational Software Architect makes it possible to customize the existing units to your own needs.

This tutorial guides you through the process of developing a custom-made virtualization framework to use with modeling for the IBM® Power Systems™ platform with PowerVM technologies. Rational Software Architect has a rich deployment topology editor that contains explicit support for several virtualization technologies and, equally important, makes it easy to customize existing elements. Using PowerVM modeling as an example, you learn how to quickly modify generic units to adapt them to new scenarios.

About this tutorial

This tutorial is broadly divided in three major steps:

  1. A quick introduction to physical deployment modeling, using discrete servers
  2. A hands-on overview of some of the existing virtualization technologies explicitly supported by Rational Software Architect
  3. The gradual development of PowerVM virtualization support by using the Rational Software Architect customization tools

Although the customization process is straight-forward, this tutorial assumes no prior experience with Rational Software Architect. Therefore, some emphasis is given to showing how deployment topologies are created and populated. By the time the customization process begins, the core concepts of topologies have already been demonstrated and it is a natural progression.

Objectives

In this tutorial, you will learn about Rational Software Architect deployment topologies, how to model a physical infrastructure, and how to model different virtualization technologies. By the end of this tutorial, you will have successfully implemented support for PowerVM modeling and will have learned the fundamentals of customization that can be used in many other scenarios.

Prerequisites

This tutorial is not based on any specific operating system. However, the examples use Linux, so any file system operation should be converted to the equivalent if some other operating system is used.

This tutorial requires no prior knowledge of modeling deployment topologies. Some familiarity with Rational Software Architect is helpful but it is not assumed.

System requirements

The sole requirement of this tutorial is Rational Software Architect Version 8.0 (or later) with the Deployment Modeling capabilities enabled.


Creating a topology

  1. Start Rational Software Architect.
  2. Create a new project by selecting File > New > Project.
  3. From the General category, select Project and then click Next.
  4. In the Project Name text field, enter powervm_test.
  5. Click Finish to create the new project.
Figure 1. Creating a project
project selected

Now that you have created the project, you will add a topology to it.

  1. Right-click on the project name in the Project Explorer and select New>Topology.
Figure 2. Adding a new topology to the project
Menu with New > Topology selected

Larger view of Figure 2.

  1. When the topology creation window opens (see Figure 3), select the Blank Topology in the Basic Topologies category.
  2. Name it test_topology, and click Finish
Figure 3. The New Topology wizard
Name entry field shows: test_topology

Rational Software Architect has different perspectives, and each one changes the way that information and tools are presented in order to make the working environment more aligned with the goal of the model being worked on.

  1. After creating a new topology, you will be given the choice to change to the Deployment perspective. Accept the offer by clicking OK.

You have now created a new topology (see Figure 4). You will see a Welcome note. It is a good idea to explore the topics suggested. For the purposes of this tutorial, though, close the Welcome note.

Figure 4. A blank topology
Window shows a blank topology diagram

Larger view of Figure 4.

You are now ready to explore the topology editor.


Physical deployment topologies

Before addressing virtualized environments, you will start by modeling a simpler scenario: representing the deployment of an application into an operating system that is, in turn, installed on a specific server. Several important concepts that you need to understand later in this tutorial are built in this section.

You will use the following units to successfully model this scenario, all of them present in the palette that is, by default, on the right side of the screen, next to the diagram editor.

Conceptual and concrete units

It's important to note that you will be using realized, ready-to-use units, not conceptual units. Be sure to select LDAP Server, not (LDAP Server). Although, for most of the examples, the behaviour would be the same, conceptual units are different from nonconceptual ones in several ways, one of them being the enforcing of certain requirements.

Conceptual units, in general, provide information where a realized unit would provide a warning, which is logical because a conceptual unit will have to be realized eventually, and only then will the requirements be enforced. As a general rule, conceptual templates have far fewer default values specified than their physical counterparts and can be converted to a realized, concrete unit by using the Properties values or, most commonly, linked to a nonconceptual unit by a realization link.

  • LDAP Server: Found in the Middleware templates
  • Power Server: Found in the Hardware templates
  • x86 Server: Also found in the Hardware templates
  • AIX 5L: Found in the Operating Systems templates
  • Linux: Also found in the Operating Systems templates

Hosting an LDAP server in IBM AIX systems

  1. Drag LDAP Server into the diagram, and notice the warning icon in the bottom-left corner. (See Figure 5.)

Clicking it will display information about the error that was detected. When no errors are found, the icon turns into a blue icon with an i in it (lowercase letter i). If you click, it will display information, including optional actions that could be useful but aren't strictly required. This is very useful, though, and should be used constantly, because it provides real-time information concerning the consistency of the model, as well as being a huge time-saver, because the proposed actions are not only context-sensitive but take the surrounding environment into consideration.

Figure 5. Adding the LDAP server to the topology
An LDAP server unit in the diagram editor
  1. Click the warning icon. As Figure 6 indicates, the LDAP server needs to be hosted in an operating system.
Figure 6. Warning message about the LDAP server
Warning hosting the server in an OS
  1. IBM® AIX 5L™ for POWER™ is a UNIX operating system, so add it to the diagram: drag the AIX 5L template into the diagram.

You now have a representation of an AIX deployment. If you look at the warning icon, you will notice that this unit also contains warnings. But focus on the LDAP Server for now and leave the AIX warnings for latter.

  1. Click the LDAP Server warning again, and this time, click the specific entry that it contains: "Unit ('LDAP Server') must be hosted (OperatingSystem)." One of the actions suggested is to host it on the no hostname unit, which is the AIX instance that you added but haven't properly named yet.
  2. Select that option by selecting that action in the lower pane and double-clicking it. This will host the LDAP Server unit in the AIX instance.
Figure 7. Using proposed actions
server warning action to host selected

Notice that the warning has disappeared from the LDAP Server, which means that all mandatory requirements are now met. There is a hosting link between the LDAP Server and the AIX instance, as shown in Figure 8.

Figure 8. LDAP server hosted on an AIX instance
LDAP server unit linked to AIX via hosting link

Larger view of Figure 8.

Capabilities and requirements

To see the requirements of any unit, go to the Requirements tab of the unit Properties, which is displayed just under the diagram. In the case of the LDAP Server, there is exactly one requirement: Host on Operating System. Follow the same process to see the Capabilities of the unit.

Different relationships have different links. Hosting is represented by an arrow with two parallel lines. Later in this tutorial, you will see how dependencies and membership relationships have different visual queues.

It's time for you to take a look at the AIX unit, which, as mentioned earlier, contained warnings.

  1. Click on the warning icon of that unit. A list of errors will appear (see Figure 9) that includes the need to set the hostname, the root password, and to host the operating system is a physical server.
Figure 9. AIX instance warnings
Lack of hostname, root password, hosting

You will tackle the issues concerning the hostname and the root password first.

  1. Following the previously explained method of selecting each error and choosing a proposed action, name the AIX host gemini (by using the Set hostname action proposed for the "hostname" is undefined error), and set the root password to 123 to address the userPassword is undefined error under the root user.
  2. Click the warning icon again will present a final error regarding the lack of host (Figure 10).
Figure 10. AIX hosting requirement warning
Only the unsatisfied hosting requirement remains

Adding physical servers

The AIX instance must be hosted on a server. To find out more about this requirement take a look, as noted above, in the Requirements tab in the Properties unit, which is at the bottom of the screen, by default.

Figure 11. Viewing the AIX unit requirements
details of the requirements

Larger view of Figure 11.

The requirement specifies that AIX can be hosted in any unit with the server.Server capability, which includes x86 servers. This can seem strange, but upon further inspection you will note that there is one constraint for this requirement. Click on the Constraints tab in the Properties view.

Figure 12. AIX hosting constraint
entry that specifies cpuArchitecture=powerpc

Larger view of Figure 12.

The constraint specifies that the server hosting it must implement the PowerPC architecture. To test this drop two server units into the diagram: a Power Server and a x86 Server.

Figure 13. Adding servers
Power server and a x86 server added

Larger view of Figure 13.

In Rational Software Architect there are several ways to perform the action so you will use a different method to host this unit. Place the pointer over the AIX unit. This will display a yellow arrow. Click on it and drag it to an empty space. A pop-up will appear asking the type of relationship we want to indicate. Choose Hosting link.

Figure 14. Using link discovery
popup connected to the AIX unit with Hosting Link selected

Larger view of Figure 14.

Rational Software Architect will present a list of option that are compatible with the requirements. Since as you have seen before there is a mandatory requirement regarding the CPU architecture that can host an AIX instance only the Power Server unit appears on the list. Select it and click OK.

Available target units. Power Server matches.

The AIX instance is now hosted and all warnings have disappeared from it, as shown in Figure 16. The Power Server doesn't have any requirements, so it never did display a warning.

Figure 16. AIX instance hosted on Power server
diagram with AIX instance connected to Power server via hosting link

Larger view of Figure 16.

Hosting Linux in the x86 server

Follow the same procedure to add a Linux unit and another LDAP Server unit, host the Linux unit in the x86 server and the new LDAP Server in the Linux unit.

Figure 17. AIX and Linux final stacks
The window shows the diagram with the two final stacks

Larger view of Figure 17.

Automatic arrangement of units

The examples in this document use the Select all and the Arrange all options in the toolbar, which automatically rearranges all units and links according to a pattern defined in the Properties topology.

In terms of visual style you are seeing the units hosted outside of their host, with a hosting link indicating the relationship. Depending on the purpose it can be useful to have a more compact view. This is easily achievable via the Show Unit on Host toolbar options or by simply dragging the unit into the host. This also works to create a new hosting relationship should one not exist. Dragging the units outside has the reverse effect.

You can mix and match different visual arrangements inside the same diagram. This can be useful to give a different focus to particular components. Figure 18 shows the two different stacks arranged in different ways.

Figure 18. Different ways to view hosting relationships
LDAP server is connected to Linux via a hosting relationship link

Larger view of Figure 18.

Now that you have successfully experimented with physical deployments, it is time to see what changes when introducing virtualization options. The next sections give an overview of some of the possibilities.


Modeling virtualized topologies: x86 with VMware

The present version of Rational Software Architect doesn't specifically address PowerVM. It does, however, have a Virtualization palette category with dedicated units for VMware and Xen, plus z/VM. Given that you will later be using its simple but powerful unit customization facilities to model PowerVM deployments, it makes sense to first explore how virtualization is modeled in other hardware platforms that have explicit support in Rational Software Architect.

  1. Create a new topology by following the same steps as before, and name it virt_topology.
  2. Add an LDAP Server and a Linux operating system unit, and create a hosting link between them.

Note about these instructions:
For the rest of this tutorial some details that were already previously covered will be omitted.

Figure 19. Redoing the LDAP deployment
LDAP Server connected to Linux unit via hosting link

Larger view of Figure 19.

Adding the virtualization layer

  1. Rather than creating a server, as you did before, drag a VMwareESX unit from the Virtualization palette into the diagram.

Because VMware ESX is not implemented in firmware, it needs to be deployed in an x86 server, as indicated in the list of warnings for the unit. You can view the VMwareESX unit as representing the software that needs to be installed in order to provide a x86 server with an hypervisor that allows the virtualization of resources.

  1. Add a x86 server unit to the diagram and host the VMwareESX unit in it
Figure 20. VMware ESX hosted in an x86 server
VMware ESX unit is linked by a hosting link to the server

Larger view of Figure 20.

At first glance, you could assume that this VMware ESX unit would directly host the several operating systems, but this unit doesn't have that capability. You can try it, though. If you try to create a hosting link between Linux and VMware ESX, a pop-up window will appear to allow you to create a new capability on the target. This is not what you want, but it is a useful feature to be aware of, especially for unit customization. The hypervisor doesn't directly host an operating system; it hosts a virtual image that represents the virtualized resources that can be used by a virtual server.

  1. Add a VMware Virtual Image to the diagram, and host it in the VMware ESX unit. For this tutorial the VMware ESX unit was given lupus as an hostname. The result should be similar to Figure 21.
Figure 21. Adding a virtual image
VMware Virtual Image unit with hosting link to VMware ESX unit

Larger view of Figure 21.

Virtual images and virtual servers

At first look, this way of modeling virtualized environments can seem overly complex. You might wonder: why not use a Virtual Image as the representation of the virtual hardware where an operating system can be deployed, rather than having it as an extra layer?

Consider working on a physical-to-virtual transformation in which a topology model for the physical infrastructure already exists. The Virtual Image approach makes it trivial to simply "wrap" the physical environment inside of the Virtual Image container, rather than having to modify the hosting relationship between the operating system and the physical server. Considering that the physical server could have relevant information (number of CPUs or size of RAM, for example), this would mean either having to manually duplicate the information or discarding it altogether.

To better understand the concept behind virtual images, take a look at the list of Capabilities of the unit. Capabilities and requirements, with associated constraints, define most of what you need to know about any unit. Notice that it needs to be hosted on a server, as seen previously, and that it must have a member that is a server. At first, this can seen odd, because there isn't a warning sign in the unit. If you take a closer look at the Constraints tab, the lack of warning is clarified: the number of servers that must be a member of the unit is either one or zero.

It is important to note that this VMware Virtual Image unit doesn't specify operating systems as possible members, but servers, which will, in turn, host the operating system.

  1. Add a x86 server to the diagram and make it a member of the ESX unit by dragging and dropping this server into the VMware Virtual Image unit. Membership is always shown by displaying the member in the host. Figure 22 shows the topology up to this point.
Figure 22. Using a Virtual Image as a container
solid arrow indicates membership relationship

Larger view of Figure 22.

Modeling virtual resources

Before hosting the Linux unit in this virtual server, you will probably have noticed by now that clicking a unit also displays a small tool tip with icons, which are a sort of "quick add" entries that show what is most commonly hosted or grouped in that unit. Doing this in an x86 server shows a list of Microsoft Windows and Linux operating systems. In an IBM Power Server, it will show only AIX, and in AIX, it will display icons for users, groups, file systems, and so forth. In the VMware Virtual Image unit it will display these definitions:

  • VMware Virtual SCSI Disk Definition: This represents the configuration of a virtual disk, as done by ESX, that is made available to the virtual image.
  • VMware Virtual IDE Disk Definition: As above, but for an IDE disk.
  • VMware Virtual Ethernet NIC Definition: represents a NIC that is made available to the virtual image
  • VMware Virtual Server Snapshot: A snapshot configuration

As noted previously, these definitions represent the virtual resources that are made available to the virtual image, and thus, ultimately, to the hosted operating system. These units aren't required by the virtual image, and their use depends on the specific deployment being made and the level of detail that the topology will reflect.

Add a VMware SCSI Disk Definition and a VMware Virtual Ethernet NIC Definition to the diagram. The warnings and the Requirements indicate that they must be hosted in a VMware Virtual Server Definition, which is a capability that the existing VMware Virtual Image unit implement.

Figure 23. Adding virtual resources to an image
one Virtual NIC and one Virtual SCSI disk

Larger view of Figure 23.

As you can see in Figure 23, there is an information icon in both the virtual image and the virtual NIC (hosting units always show warnings and information inherited from the units they host), which says that there is an optional requirement that isn't satisfied: the VMware Virtual NIC depends on a Layer 2 interface. Or, putting it another way: the Virtual Ethernet NIC must be backed by a physical one. This is a level of detail that falls outside of the scope of this tutorial. Please see the developerWorks article titled "Modeling virtual systems with the IBM Rational Software Architect deployment architecture tools," which is referenced in the Resources section.

You now have, in one end, an LDAP server hosted in a Linux instance, and on the other a x86 server that hosts VMware ESX, which in turn hosts a Virtual Image. This Virtual Image hosts two virtual resources (a disk and an Ethernet NIC) and has as a member a x86 server that represents the virtual ability to host operating systems.

Tying it together

You can now finally tie the two ends together and host the Linux instance in the x86 Server that is contained in the VMware Virtual Image. Set the hostname of the Linux instance if you haven't done so yet. All warnings disappear from the model and you should have something very similar to Figure 24.

Figure 24. Hosting Linux on the virtualized infrastructure
hosted on VMware ESX in the x86 server

Larger view of Figure 24.

This sums up the main concepts behind modeling VMware virtualization deployments in Rational Software Architect, which are largely the same when using Xen instead of VMware.

The next section will show you one different approach in virtualization modeling.


Modeling virtualized topologies: System z and z/VM

You will now take a look at how virtualization is modeled in System z. The virtualization capabilities of System z were pioneering when they were introduced, and Rational Software Architect has explicit support for them. When talking about System z virtualization, it is important to note that there are several different ways to implement it, including these:

  • LPAR: System z allows the creation of several LPARs, which are then managed, in terms of resources, by PR/SM.
  • VM Guest: IBM® z/VM® is an operating system that has the ability to run other operating systems as guests (the typical z/VM environment uses CMS as an operating system), including another copy of z/VM.

In this section, you will deploy to a z/VM guest, because that's the most common choice when considering Linux on System z.

Importing topologies

It is possible and encouraged to use the same base topology that represents the LDAP deployment in Linux and then import it into each of the different virtualization topologies. This would allow you to use the same basic topology,an LDAP server hosted in Linux, and model its deployment in different scenarios. This tutorial doesn't use this approach, mostly to avoid introducing a different concept but also to allow more practice in the creation and linking of units.

To clearly show that we're using nonshared units, the hostnames of the units in the examples are different in each topology.

Creating the base topology

  1. Create a new topology named systemz_topology, and recreate the LDAP server deployment in Linux:
    1. Add an LDAP server and a Linux operating system, and then create a hosting link between them.
    2. Set the root password and hostname for the Linux unit.
  2. Drop a System z Server from the Hardware palette category into the diagram. Clicking the warning indicator will show you that a System z server needs at least one LPAR.
  3. Add an LPAR, also found in the Hardware palette, to the diagram, and host it on the System Z server by creating a hosting link.
  4. Now add an IFL (Integrated Facility for Linux), which is a dedicated CPU for Linux, to the LPAR. You can easily perform this action by clicking in the LPAR unit.
  5. When a toolbar appears, select the icon that depicts a CPU with a penguin. The LPAR contains a warning (Figure 25), because an LPAR with an IFL must directly host either Linux or z/VM.
Figure 25. An LPAR with an IFL has specific requirements
suggested actions hosting a z/Linux or z/VM in the LPAR

Larger view of Figure 25.

  1. Click the warning icon and select the existing warning.
  2. Double-click the Host "ZVM" on LPAR "LPAR" action proposed.

Figure 25 shows the final result of the actions taken up to this point.

Figure 26. Hosting a z/VM instance
The diagram shows a z/VM unit connected

Larger view of Figure 26.

The IFL that was previously added to the LPAR shows an information icon, because an IFL can optionally be hosted in System z server.

  1. Click the information icon of the IFL, select the Unit (IFL) may be optionally hosted () entry, and double-click the Host "IFL" on "System z Server" action proposed. This relation represents the fact that the IFL is physically present in the System z server but attributed to the LPAR.

Notice the difference between the arrows that represent the relationship between the host and the contained unit. In the System z Server, the IFL is hosted; whereas, in the LPAR, the IFL is a member.

If you try to host the Linux instance in the created z/VM unit, it will not work. Just like in the VMware scenario, you need an intermediate layer that indicates that the operating system is running in a virtual image, not directly from the z/VM instance.

  1. Drag the z/VM guest unit from the Virtualization palette and into the diagram (or use the z/VM unit toolbar, as previously shown) and host it in the z/VM unit.

Dealing with hosting errors

You are now ready to host the Linux instance. Link the Linux unit to the z/VM Guest to create a hosting relationship.

Figure 27. Linux on z/VM hosting error
diagram with Linux connected to z/VM guest via hosting link

You will notice that, as in Figure 29, the hosting link has a warning. Clicking on it will reveal that the Linux unit you have been using can't be deployed to z/VM.

Figure 28. Hosting error details
the CPU Architecture (z/VM Guest) is invalid

There are several different ways to solve this, and some of them are provided by the warning dialog. The most direct approach is to use an appropriate template. Instead of Linux, which is x86 specific, use z/Linux, that can be found on the System z stack in the Operating Systems palette drawer.

Using a shortcut to add units

The Ctrl-t shortcut will invoke a pop-up that displays all the available templates and allows real-time searching, narrowing down the results with each key press. It also maintains the most recently used units at the top.

One alternative that you will use in this tutorial, to show how units can be customized, involves removing constraints. Because Linux runs on pretty much everything (especially true if you consider the available CPU architectures in Rational Software Architect), you will just remove the constraint associated with the hosting requirement of the Linux unit. Select the Linux unit and go to the Requirements tab of the Properties unit. Select the Server requirement and, in the content area to the right, select the Constraints tab (Figure 29).

There is one constraint listed, cpuArchitecture = intel. Select and remove it by clicking on the red cross above it.

Figure 29. Removing a constraint
Linux unit Properties with Requirements tab selected

This immediately removes the warning and the model is error-free, as shown in Figure 30.

Figure 30. The final model without any warnings
The diagram shows the final model

This Linux unit you created is generic in terms of hardware hosting requirements. Another option would be to merely change the constraint to make it require a System z architecture, in which case we would have created a unit very similar to the standard z/Linux one. In the next sections we will see how this kind of customised units can be added to the palette.

Notice that with System z you didn't use any Virtual Disk or NIC definitions. In Rational Software Architect System z virtualization doesn't use them, but in turn there is fine-grained support for different CPUs (CP, IFL, ZiP, and so forth) and how they are hosted and used.

In the next sections you will start developing you own virtualization approach.


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
The diagram shows two servers

Larger view of Figure 31.

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.

Creating the initial topology

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
The windows shows the initial topology

Larger view of Figure 32.

Customizing existing units

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
The window shows the entire Virtualization palette.

Larger view of Figure 33.

  1. Drag and drop a conceptualVirtual Image into the diagram. Notice that what would be warnings in a concrete unit are presented as information in a conceptual one.
  2. 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
hosting requirements of the Virtual Image unit.

Larger view of Figure 34.

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
The window shows the capabilities of the Virtual Image unit.

Larger view of Figure 35.

Your next step will be to create a concrete unit that can be used to model PowerVM LPARs.

  1. 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
entry called PowerVM LPAR

Larger view of Figure 36.

  1. Now, make the following changes:
    1. 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.
    2. Change the Image id to PowerVM LPAR. The Image id field is also in the Capabilities tab.
    3. Select the field named no imageId and change the appropriate field in the content area to the right.
  2. To make this unit reusable, you will now add it to the palette:
    1. Right-click the unit and select Add to Palette.
    2. 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
the label, a description and an icon.

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.

  1. 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
entry virtualization.hypervisor selected.
  1. 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
The diagram shows the customized units

Larger view of Figure 39.

Finishing the topology

When to use the hypervisor-enabled server

Unlike z/VM, the hypervisors in PowerVM cannot be nested. This means that, although z/VM can host a copy of z/VM, in Power Systems, an LPAR will directly host only an operating system. This is why you should use the standard Power Server unit inside the custom-made PowerVM LPAR.

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.

  1. 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
No warnings appear in any unit

Larger view of Figure 40.

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.


Virtual resources and PowerVM

The work that you have done so far already provides a functional way to model PowerVM deployments. In this section, you will go a step further and implement some of the behavior present in the VMware scenario, namely virtual disks and NICs that represent the virtual devices configured in the HMC to be used by the operating system in the LPAR.

There are two important points that you need to take into consideration:

  • Using generic units as a starting point for new units is extremely flexible, quick, and easy to manage, but there is only so much that can be done. In particular, you can use only existing capabilities. (Rational Software Architect offers ways to create new units and domains, but that it beyond the scope of this tutorial.) You could use this approach, for example, to add a Virtualization.PowerVMHypervisor capability that would be more tailored to your needs. For more information, see the developerWorks article Extending the topology editor with custom technology domains referenced in the Resources
  • One of the best points of Rational Software Architect is the support for model-driven development. This means that in many cases there is built-in support for turning diagrams into real configurations that can be deployed, much in the same way that it creates Java header files from UML diagrams. Our customizations are merely aimed at providing a coherent model and do not support advanced functionality, such as automatic creation of HMC configuration files that would configure a server according to our model.

You will use the same general approach as in the previous section: take a generic conceptual unit and customize it to your needs. You will need to use these two definitions:

  • The conceptual Virtual Disk definition
  • The conceptual Virtual Ethernet NIC definition
  1. Using the same topology as the previous section, add a conceptual Virtual Disk Definition to the diagram, and deselect the Conceptual check mark, as before. The result is a generic virtual disk that can be hosted in a virtual image.
  2. Now, add a stereotype named PowerVM Virtual Disk Def to the unit.

As it is right now, this PowerVM virtual disk would happily allow a hosting relationship with, for example, a VMware virtual image. You want to limit to the unit to a specific kind of virtual image so that this newly created PowerVM Virtual Disk Definition will be hosted only by your custom-made PowerVM LPAR.

As mentioned previously, Rational Software Architect offers ways to add entire new capabilities and domains. For the purposes of this tutorial, though, a simpler approach is sufficient, and one possibility is using stereotypes.

  1. Select the Virtual Disk Definition that you just customized, and go to the Requirements tab.
  2. Select the HostingReq requirement, and go to the Constraints tab.
  3. To add the constraint, click the green plus sign in the constraints editor, and select Stereotype from the pop-up window.
  4. In the dialog window that appears, type PowerVM LPAR in both the Caption and Includes fields.
  5. Click Close when you are finished.

Figure 41 shows the constraint added.

Figure 41. Adding hosting constraints to the virtual disk
Stereotype (PowerVM LPAR) includes [POWERVM LPAR)]

Larger view of Figure 41.

  1. Now, try to host you virtual disk in the PowerVM LPAR.

You'll find that the hosting link displays an error (see Figure 42). The warning tells you that the constraint failed because the PowerVM LPAR Virtual Server definition doesn't have the appropriate stereotype.

Figure 42. Virtual disk hosting error
Hosting relationship error and proposed action

The reason that this happened is because the constraint that you specified was not made in relation to the stereotype of the hosting unit but, instead, to the stereotype of a specific capability present in the hosting unit, namely virtualization.VirtualServerDef.

  1. Using the action proposed by the error resolution dialog, add the stereotype to the Virtual Server Definition capability in the PowerVM LPAR unit. (See Figure 43.)
Figure 43. Adding a stereotype to satisfy hosting requirements
The window shows the PowerVM LPAR Capabilities

Larger view of Figure 43.

  1. Repeat the process with a conceptual Virtual Ethernet NIC Definition.

The result, shown in Figure 44, will be quite similar to the VMware topology.

Figure 44. Final topology with virtual devices
two virtual devices inside the PowerVM LPAR.

With the addition of virtual devices, the PowerVM virtualization possibilities that you have built during the course of this tutorial are already complete. The next section adds a final touch that could be useful.


Requiring an HMC

As a final exercise, you will make the PowerVM Server require a Hardware Management Console (HMC). Although there are situations where a HMC isn't strictly needed, such as with a standalone server or server with an IVM, in practice and for our purposes here, consider an HMC a requirement.

  1. Using the same topology as before, you will start by creating an HMC. The Hardware Management Console is an x86 server with a customized version of Linux. By now, you already know how to model this by using an x86 Server unit and a Linux unit.
  2. Add an HMC stereotype to the x86 Server.
  3. To make things a bit more interesting, change the appearance of the unit to make it stand out. You can do that by using the Appearance properties tab and selecting a different appearance from the list.

Figure 45 shows the HMC in tones of green.

Figure 45. Adding an HMC
Diagram: x86 server (green), HMC, Linux instance

Larger view of Figure 45.

You can add this stack composed of the server and the OS to the palette if you wish. The palette can contain templates composed of several units and relationships.

You need to make the PowerVM Server depend on at least one HMC. This means that you need to create a mandatory dependency requirement on the PowerVM Server unit.

  1. In the Requirements tab of the PowerVM Server unit, click the Add Requirement icon positioned above the requirements editor.
  2. Enter Needs HMC as the value of the Caption, set the Link type to dependency, and set the Type to server.X86Server.

Figure 46 shows the requirement added.

Figure 46. Adding the requirement to the PowerVM unit
The window shows the PowerVM Server Requirements.

Larger view of Figure 46.

  1. This requirement is set on server.X86Server, which is not specific enough. Therefore, add a constraint to the Needs HMC requirement to the HMC stereotype.
Figure 47. Adding a constraint
PowerVM Server: Needs HMC selected. Constraints.

Larger view of Figure 47.

If you try to create a dependency link between the Power VM Server and the HMC, a pop-up window will appear showing the matching between requirements and capabilities. As can you can see in Figure 48, there is no 100% match between the requirement that you specified and the capabilities of the HMC unit. The reason is the same as in the previous sections: the dependency is enforced based on the stereotypes of the capability, not the unit itself.

Figure 48. Matching requirements and capabilities
Two panes: source requirements, target capabilities

You need to add the HMC stereotype to the server.X86Server capability of the HMC.

  1. Go to the HMC unit Capabilities tab, select the x86 Server capability, and add an HMC stereotype.
Figure 49. Adding the stereotype to the server capability
The window shows the HMC unit Capabilities.

Larger view of Figure 49.

  1. This time, use the PowerVM Server warning icon to create the dependency link. Click the warning icon of that unit.
  2. When the warnings pop-up window appears, as seen in Figure 50, double-click the proposed action to create a dependency link to the x86 Server unit.
Figure 50. Creating the dependency link
PowerVM Server warning and proposed action

Your model is now error-free.

Figure 51 shows the topology in its final state. You took it through several stages, each one building on the previous. Now you can use it for modeling not only LPARs but also virtual devices and HMC requirements.

Figure 51. The final topology
The diagram shows the PowerVM Server connected to the HMV via a dependency link

Larger view of Figure 51.


Additional possibilities

This concludes this tutorial. You now have custom units in your local palette that can be used to good effect in modeling PowerVM deployments. Above all, you should feel more comfortable in customizing Rational Software Architect standard units to adapt them to a wider range of scenarios.

There is plenty more that could be done in terms of PowerVM deployment, for example:

  • Require more than one HMC for availability purposes
  • Create completely new domains and capabilities
  • Implement something to model Virtual I/O servers
  • Learn how to model something akin to the System z CPU allocation model

In this tutorial, we barely touched the surface of what you can do with the deployment modeling features. Exploring some of the link types, for example, reveals numerous possibilities regarding collocation rules and capacity planning.

Rational Software Architect deployment topologies are both simple to use and to customize, yet very clear and intuitive to use, too. The Help system contains examples and tutorials that help you understand all of the potential uses. Explore the Resources section here to start learning more.


Download

DescriptionNameSize
RSA project file for this tutorialrsa_powervm.zip22KB

Resources

Learn

Get products and technologies

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Rational software on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Rational, DevOps
ArticleID=630010
ArticleTitle=IBM PowerVM deployment modeling features for virtualization
publish-date=03082011