Installing HP Cloudsystem 9.0 - Part 8

Installing HP Cloudsystem 9.0 - Part 8

Command Line Tools & Glance image Deployment:

My next step is to get the command line tools up and running and to upload a small image to Glance that I can use to test a few designs.

Oh! This is interesting, Glance is only available in the Linux tools package this time.....how are you meant to upload your images I wonder?!! Only HTTP locations are supported.

Well, I extracted the windows tools to a folder and created a batch file to set my environment variables as follows:

Filename: env.bat

set OS_USERNAME=Admin
set OS_PASSWORD=<Password used during setup>
set OS_TENANT_NAME=demo
set OS_AUTH_URL=https://192.168.12.200:5000/v2.0
set OS_REGION_NAME=RegionOne

Then I can run commands like:
nova --insecure list
nova --insecure hypervisor-list

+----+---------------------+
| ID | Hypervisor hostname |
+----+---------------------+
| 3  | domain-c261(Cloud)  |
+----+---------------------+

And so on. Without Glance it's going to be interesting trying to get my windows images uploaded so I'm cheating and used the Glance form CloudSystem 8.1 Tools!! I could also deploy a linux VM for the purpose or a web server but I've only used Windows in the past so I'll see how this goes.

nova --insecure service-list

+----+------------------+-------------+----------+---------+-------+----------------------------+-----------------+
| Id | Binary           | Host        | Zone     | Status  | State | Updated_at                 | Disabled Reason |
+----+------------------+-------------+----------+---------+-------+----------------------------+-----------------+
| 1  | nova-cert        | cc2         | internal | enabled | up    | 2015-10-09T13:46:43.000000 | -               |
| 4  | nova-conductor   | cc2         | internal | enabled | up    | 2015-10-09T13:46:43.000000 | -               |
| 7  | nova-scheduler   | cc2         | internal | enabled | up    | 2015-10-09T13:46:43.000000 | -               |
| 10 | nova-cert        | cc1         | internal | enabled | up    | 2015-10-09T13:46:51.000000 | -               |
| 13 | nova-conductor   | cc1         | internal | enabled | up    | 2015-10-09T13:46:51.000000 | -               |
| 16 | nova-scheduler   | cc1         | internal | enabled | up    | 2015-10-09T13:46:51.000000 | -               |
| 19 | nova-conductor   | cmc         | internal | enabled | up    | 2015-10-09T13:46:50.000000 | -               |
| 22 | nova-cert        | cmc         | internal | enabled | up    | 2015-10-09T13:46:50.000000 | -               |
| 25 | nova-scheduler   | cmc         | internal | enabled | up    | 2015-10-09T13:46:50.000000 | -               |
| 28 | nova-consoleauth | cmc         | internal | enabled | up    | 2015-10-09T13:46:50.000000 | -               |
| 30 | nova-compute     | Labvc-Cloud | nova     | enabled | up    | 2015-10-09T13:44:57.000000 | -               |
+----+------------------+-------------+----------+---------+-------+----------------------------+-----------------+

My nova-compute service went down at one point, so I rebooted the Compute Host and toggled the following commands until the service came up AND the state also showed up:

nova --insecure service-enable Labvc-Cloud nova-compute
nova --insecure service-disable Labvc-Cloud nova-compute

So, let's get an instance up and running! I initially had no luck getting uploaded images to work, Everytime they deployed and hit the VMware Hypervisor they gave an error about no valid hosts. What I found when I broke down the advanced properties is that they have changed between CloudSystem 8.1 and 9.0. Undoubtedly this is because of the switch to Helion Openstack 1.1.1 and a later version of Openstack (Juno stable release 2 I think it is). Anyhow, the old Glance commands are not working so I kept trying combinations until a Cirrus image worked fine and then that indicated the advanced properties I was using with windows were no longer all valid.

So, the same procedure is used in vCenter to export an existing template into an OVF which splits out the VMDK disk we upload. Select a VMware Template and then export it as an OVF (I'm using the old C# client here):

Next wait until the export has finished and then if you examine the folder specified, a subfolder with the template name will have the files you need. 

This is the list of files:

We use Glance to upload the VMDK file and leave behind the VMX so when we configure the image it's important to add the right advanced properties so when an instance is deployed we get a well performing VM back. Make sure you use a unique image and disk name for the Glance upload - i.e. if you're re-uploading the same image more than once after a patch etc CHANGE THE DISK NAME!! You'll only experience connection reset by peer errors 10054 if you throw Glance a duplicate disk file name up, at least that's what I experienced! Here is the command I used after I changed the VMDK name:

glance --insecure image-create --name 2012R2Test --disk-format vmdk --container-format bare --file "C:\Temp\cloud\2012R2 Std Template\2012R2_rdisk1.vmdk" --is-public True --is-protected False  --progress --property vmware_ostype=windows8Server64Guest --property vmware_adaptertype=lsiLogicsas --property vmware_disktype=sparse --property hw_vif_model=e1000e

Now we have an image in Glance. If you want to check the Properties of an image do this:

glance --insecure image-show 2012R2test

And you get the same box as shown above. To update a parameter you use the image-update command:

glance --insecure image-update "Server 2008R2" --property hypervisor_type=vmware --property vmware_ostype=windows7Server64Guest --property vmware_adaptertype=lsiLogicsas --property hw_vif_model=e1000e

The only 4 values you need to set are shown above. The optional settings you may wish to tweak are:

hw_vif_model:
e1000, e1000e, VirtualE1000, VirtualE1000e, VirtualPCNet32, VirtualSriovEthernetCard, and VirtualVmxnet.

vmware_adaptertype:
lsiLogic, lsiLogicsas, busLogic, ide, or paraVirtual

os_type (2008 R2 , 2012 R2):
windows7server64guest, windows8server64guest

Note: There is no VMXNET3, this appears to be due to a bug Openstack and was patched in May 2015 but this would not have been in Helion Openstack 1.1.1. This should be patched down the road.

Now let's look at the uploaded image in Foundation:

The next thing to do it to test an instance deployment. Assuming you have an activated vCenter & Cluster let's deploy an instance. I created a Windows Flavor as follows:

The instance flow is as follows:

I left all the other options at default, I've captured them here just to show them:

The instance starts spawning. Basically it's staging the Glance disk BACK to a Datastore in VMware, then it copies it and creates a linked clone to this copy. The process usually takes 20 minutes for the first VM and seconds for subsequent ones on the same Datastore. Keep a close eye on free disk space as the images take up a lot of space as you do testing of different variations. Also from time to time if you find an instance request trigger NO activity in vCenter, reboot your compute host (don't forget to shutdown the ovsvapp first and bring it up afterwards!). Or look at the Nova issue I explained earlier.

Now we have an instance booted and ready to go:

I'm not going to cover Cloudinit but this is a means to pass customization parameters to windows VMs to go beyond "build me an OS...."
https://cloudbase.it/cloudbase-init/

Now you have a instance it's time to play...!!

Update: Note to self - the OO Appliance credentials are "administrator" and the password you use during first time setup.

VMware SRM - 3PAR Certificates

VMware SRM - 3PAR Certificates

At a certain point you will upgrade the 3PAR Firmware and during one of those code releases, 3PAR certificates were introduced. The issue is that your SRM will stop working until you've rectified this. The SRA User Guide covers the TPDSrm.exe which is located somewhere under the folder C:\Program Files (x64)\VMware\VMware vCenter Site Recovery Manager\storage
The exact syntax you're going to need is as follows:

TPDSrm.exe viewcert

Take Note of the SysID for each 3PAR.

TPDSrm.exe removecert -sysid XXXXX

Do this for each 3PAR you have upgraded and want to replace the certificate on

TPDSrm.exe validatecert -sys <Hostname/IP Address of 3PAR> -user XXXX -pass XXXX

Yes to accept the certificate

Once you've done this for all the upgraded 3PARs you need to go into SRM and refresh each Array Manager and also each SRA Adapter for good measure. Now test against a simple recovery plan with one small LUN and a single VM. Do a TEST failover and then a Recovery Failover (Disaster Recovery method), followed by a ReProtect, followed by a Failback (Planning Migration method) followed by a ReProtect. Once all those work for a particular Array Pair you can be fairly certain the SRA is communicating correctly with the 3PAR. Next do a test failover for a Production Protection Group to make sure.

A Speadsheet with the following might be of use before beginning this task, particularly if you have many 3PAR's:

Datacenter X:
3PAR Hostname
3PAR IP Address
3PAR SysID
vCenter Server Name
SRM Server Name

Hope this helps you out, once you've got the 3PAR upgrade in the Certificate doesn't expire for many years so you won't have to revisit unless you replace the 3PAR.