IMPORTANT: Even after you can created a vApp and connected it to the Organization Network – I won’t be by default able to communicate to outside world (although two VMs within the SAME vApp would be able to communicate to each other). That’s because are no NAT or Firewall rules that would allow for outbound communication
In my previous post I created a PAYG Organization vDC. I do want to return to the topic of different resource allocation models in later blogpost, but right now I want to press on an actually get creating vApps, and running vCD generated workloads. To do that we need at least one catalog, with either media uploaded (iso) to install an OS manual (such quaint notion!) or import an existing VM either from vSphere itself OR from .OVF file. The catalog is respositry of existing VMs in most cases that have been configured for use by the tenents. How much configuration is up to you. I think if your requirements are pretty simple you could use vCD as your “storefront” – but if your really serious about application level customizations within the guest operating systems I think you would get more satisfaction out of the vFabric Application Director and/or the vCloud Automation Center (the product formerly known as DynamicOps). I’m still very much learning about how all the parts (of which vCD is just one) fit together – but from what I’ve been able to fathom – vFabric Application Director would be of strong interest to application owner who has to build out complicated multi-tier applications in automated fashion, whereas vCAC is about controlling how those applications get deployed – internally on a private vCD instance; externally through a vCloud Service Provider – or to one of many so called “public” clouds like Amazon EC2. Both have the concept of an “application blueprint” – right now the way I’m seeing it is that there are many ways of creating a catalog with different levels of complexity and flexibility. Choose your weapon.
Anyway, for now I’m taking baby-steps and just working out how all this stuff works. At some stage I will have to return to this much larger topic, for now lets focus on how the vCloud Director Catalog works.
A catalog for an Organization can be created by the vCD System Administrator, Organization Admin or anyone with the Catalog Author right. In attempt to stick with delegating responsibility on a role-by-role basis I used my Organization Admin account (rmoorcroft@corp.com) to delegate responsibility to the group called “CorpHQ – Catalog Authors”.
Delegating a Catalog Author:
1. Click the “Administration” tab
2. Expand >Members and select Groups
3. Click the Import Groups… icon
4. Add the appropriate group, and assign the privilege.
After logging in as one of my “Catalog Authors” users, I could see that vCloud Director hides the “Administration” tab – which is only visible to the System Administrator or the Organization Admin. Here the user jwild@corp.com is a catalog author…
Creating a Catalog:
1. As the Organization Admin after login into the URL provided (in my case https://vcd01.corp.com/cloud/org/corphq), and selecting “New Catalog” from the right-hand sidebar:
2. You then give the catalog a name and description
3. Share to Users and Groups: The final part of the wizard is sharing the catalog with others WITHIN the organization. A separate process called “publishing” is used to make a catalog available BETWEEN organizations. That’s something that’s enabled on the properties of the Organization that you create. For example I could give everyone in the Organization the right to at least “read” the contents of the catalog. Allowing just System Administrator, Organization Admins, and Catalog Authors to make changes inside the catalog. Everyone below a “Catalog Author” is really just a read-only user of the catalog – as they are either a vApp Author who makes new vApps from the catalog or the vApp User who merely interacts with the vApps created from the catalog.
4. Click Finish creates the catalog.
Once the catalog is created it can be populated with content. By whom? I wouldn’t be surprised if this would have to be at least the person responsible for Windows or Linux in your environment, perhaps even an application owner if it was multiple VMs that would be making up the vApp. It’s possible that the application you want to bring into the catalog is already in a .OVF format, or alternatively will need to be built from individual operating systems templates in a vApp, and the imported back into the catalog once ready for use.
Adding an .ISO image to the Catalog
I wouldn’t recommend this personally, its a lot of hard work – plus additionally if you are using “Static IP Pools” that are optionally created when you define the vCNS Edge Gateway for the Organization vDC those IP settings are not applied – and you will either need the Edge Gateway to be a DHCP server or alternatively use the guest operating systems interface to configure the IP settings. But if you must do it this way (and I did it once so at least I had the experience) then this is how it is done.
1. As the Catalog Author (or higher) select the “Catalogs” tab or “Manage Catalogs” on the right-hand sidebar
2. Select My Organization’s Catalogs
3. Select your catalog (in my case called thrillingly entitled “CorpHQ” Catalog
4. Select the “Media” Tab, and click the Upload… button.
5. Next the Upload Media dialog box, click the Browse button and locate your .ISO file. Specify a name, description, a Organization vDC, and where to store the file.
Note: I’ve sometimes found on new clients there are number of Java based pop-ups to acknowledge. Additionally, it does (in my lab at least) take a wee while for the path to the .ISO file to appear in the dialog box. I’m also wondering if I should have created a dedicate “catalog datastore” for holding this sort of content. I have one inside vCenter after all.
Once you click the upload button then an upload takes place from your local client into vCD:
Adding an .OVF to the Catalog:
To add an OVF one first needs an OVF to upload! These can be sourced from the VMware MarketPlace or from vendors website. Another source could be a VM or collection of VMs from your existing vSphere environment. Don’t forget ordinary templates in vCenter could be converted into VMs, and using the Export OVF option in the web-client converted into a portable format that vCloud Director expects.
Once exported the corresponding .OVF can be “imported” into vCloud Director.
Note: Given the size of the .OVF this import process can take time. And its not just the file copy process (the actual upload) it all so needs to be “imported” by vCD as well. And this can take sometime as well. I think that’s because there’s two uploads – first on to some “temp” area on the vCD via the “Transfer Service” and then a second “import” process when it is uploaded to the datastore selected in the storage profile.
Creating a vApp from an .ISO
The process of creating a vApp is similar if you are using .ISO or an existing .OVF image. Except one spawns a create process, and requires you define the VM in some details, as well as attaching the ISO to the VM(s), the other doesn’t require that work at all. In my case delegate the “CorpHQ – vApp Authors” rights into the CorpHQ Organization, and logged in as the user “Donald Draper”. From which he could either +Add a vApp from the Catalog or Build a New vApp.
The “Build a New vApp” allows for the option to create a “New Virtual Machine”
Note: Notice the capacity to either Add a VM from the catalog or create a new VM from scratch.
Once created (I will go into more detail on this with the .OVF method), you can open the vApp
Select the VM in the vApp, click the Insert CD/DVD from Catalog, and then select the .ISO image and click Insert
You can then power on the vApp/VM, it should boot from the DVD, and you can open a console on it to carry out the installation. [Don’t forget you have install VMware Tools at the end, and do any other post configuration tasks – such as enabled VMware Tools Time Synchronization]
Once you have installed the OS you can select the VM, select the Actions icon (in the shape of gear) and choose Install VMware Tools.
Creating a vApp from .OVF file:
1. Start by click the Add vApp from Catalog
2. Select the All Templates option, and select your imported .OVF file
Note: You can see here there is “Gold Masters” option. There really is no difference between a “Template” and a “Gold Master” from functional view point. It’s more to do with development process. So you can start off with a vApp Template being regarded as a “beta” version during a testing phase. Once the vApp Author is satisfied with the template it can be marked as a “Gold Master” its is regarded as reaching its final state.
3. Set a name and description for the vApp
4. Set a name for the VM within the vApp and what Storage Profile to use
5. Configure Networking: The next page allows us to configure the networking options. I like to enable the “Switch to the advanced networking workflow” option, as this exposes all the different IP options available. There’s quite a lot going on in this dialog box, and so its worth spending sometime walking through the options.
So firstly, as with vCenter it is entirely possible (although not particularly sane) to have a VM name different from the guest operating systems hostname. The Network pull down gives you an number of options. The “Templates” network is being inherited from the .OVF. The source of the .OVF was my template from vCenter environment that by default is configured for the “template” portgroup on my Infrastructure DvSwitch. The “CORPHQ-vCNS” is the Organizational network that allows for broader communication to the Corporate Network. If we select this option the “IP Assignment” options will become available as well. For these to appear you must enable the option “Switch to the advanced networking workflow”.
Finally, the “Add Network” option allows you to add a vApp Network to the vApp – which displays an interface to specify the vApps default gateway, subnet mask, DNS, DNS Suffix and Static IP Pool just for use by the VMs within the vApp… In my case I allowed the vApp to reside on the CORPHQ-vCNS network:
Three options are relatively striaght forward. The “Static IP Pool” pool uses the IP Pool we created during the creation of the Organizational vDC for the “Test & Dev” environment earlier – vCD will take the first available IP in the pool and assign it to the VM selected. The “Static Manual” allows you to set a static IP address from the pool rather than it being randomly chosen. Finally, DHCP assumes there is a DHCP server on the network or the vCNS has been enabled for DHCP. [More about that later!]
6. Finally, the wizard allows you to enable “Fence vApp” networking. This is popular in development environment where developers want to check out VMs for testing purposes, but do not want to have the bother of re-IP-ing the VMs. You will notice in this dialog box it says there is a “Direct” connection – I think that’s a little misleading, as it might suggest to some that this Organization is directly connected to the External Network. What this means is the VMs in the vApp will be directly connected to the Organization Network – the Organization network has vCNS Edge Gateway that acts the interface to the external network. If the VMs were behind a vApp Network or a Fenced vApp they would not be directly connected to the Organization Network.
THIS IMAGE NEEDS UP DATING FOR 5.1 network!
At this point the vApp will be created – and if you want to add an other VM of the same type, you can open the vApp, and use the + icon to add an other copy of the .OVF into it. That’s what I’ve have done here – I’ve added a second VM into the vApp and called it corphqcs01.
Of course, you should now be able to power on the vApp, and see the guest OSes in each of the VMs. With Windows VMs the deployment process automatically resets the local administrator password to make it different from what was contained in the OVF. The creator/owner of the vApp can find out these passwords by selecting the VM in this view.
In the Properties dialog box, under the “Guest OS Customization” tab you can see the randomly generated password for the local administrator account.
Note: I noticed that this password reset appears to happen for the 1st VM in the vApp, but when you add a subsequent VM (the same one from the catalog) that password reset didn’t happen (the guest customization did!)