VMware: PowerCLI for vCloud Tenants 101

PowerCLI for Tenants is a great way to offer scripting capabilities to your cloud users. It works identically to the "classic" PowerCLI but it offers a limited set of cmdlets specifically designed to provide tenants control over their cloud organizations.

This is an introductory post regarding PowerCLI for tenants in which I will explore some of the many useful cmdlets that allow users to control a cloud organization through PowerCLI.

First step is to install PowerCLI for Tenants. At this time version 5.1 release 2 is the latest available and can be downloaded here. If you already have the "classic" vSphere PowerCLI installed on your machine you need to remove it first in order to install the tenants version.

As usual, when dealing with PowerCLI, official documentation comes in handy.

In PowerCLI for tenants every user (tenant) connects to a vCloud Director server in order to run cmdlets against an organization the user is entitled to interact with. This means, for example, that different tenants can be connected at the same time to the same vCloud Director server interacting with different organizations.

Connection to an organization is performed using the following command:

Connect-CIServer -Server 192.168.243.50 -User User1 -Password MyPassword0! -Org HostileCoding

 Name              User              Org  
 ----              ----              ---  
 192.168.243.50         User1             HostileCoding  

where -Server is the vCloud Director server IP or FQDN and -Org is the organization name to connect to.

To retrieve an organization's details Get-Org cmdlet is used.

 Enabled     : True  
 CanPublish   : False  
 DeployedVMQuota : 8  
 StoredVMQuota  : 10  
 VdcCount    : 1  
 CatalogCount  : 1  
 VAppCount    : 1  
 Href      : https://192.168.243.50/api/admin/org/a3314e21-f6b8-4c53-9690-b44e96141b56  
 FullName    : HostileCoding  
 ExtensionData  : VMware.VimAutomation.Cloud.Views.AdminOrg  
 Description   : Organization Cloud  
 Id       : urn:vcloud:org:a3314e21-f6b8-4c53-9690-b44e96141b56  
 Name      : HostileCoding  

DeployedVMQuota and StoredVMQuota respectively count the maximum number of virtual machines that can be deployed and stored simultaneously by a member of this organization.

While Get-OrgVdc retrieves details about an organization:

 Href          : https://192.168.243.50/api/vdc/9fa21642-32a8-46b3-91ac-aedfc42a2937  
 AllocationModel     : ReservationPool  
 Enabled         : True  
 CpuUsedGhz       : 0  
 CpuLimitGhz       : 3  
 CpuAllocationGhz    : 3  
 CpuOverheadGhz     : 0  
 MemoryUsedGB      : 0.119140625  
 MemoryLimitGB      : 2  
 MemoryAllocationGB   : 2  
 MemoryOverheadGB    : 0  
 StorageUsedGB      : 10.25  
 StorageLimitGB     : 19.193359375  
 StorageAllocationGB   : -1  
 StorageOverheadGB    : -1  
 VAppCount        : 1  
 Status         : Ready  
 NetworkMaxCount     : 2  
 VMMaxCount       :  
 NicMaxCount       :  
 MemoryGuaranteedPercent :  
 CpuGuaranteedPercent  :  
 VMCpuCoreMHz      :  
 ThinProvisioned     :  
 UseFastProvisioning   :  
 ExtensionData      : VMware.VimAutomation.Cloud.Views.Vdc  
 Description       : Customer1 Virtual DataCenter  
 Id           : urn:vcloud:vdc:9fa21642-32a8-46b3-91ac-aedfc42a2937  
 Name          : VDC-Customer1  

Quite important are the resources limitation exposed by the previous command: StorageLimitGB, MemoryLimitGB, CpuLimitGhz, NetworkMaxCount, VMMaxCount indicate how many resources an organization is entitled to use from the cloud provider.

Get-OrgVdc retrieves a great amount of details regarding organizational's datacenter like: adopted allocation model, reservations, limits and resources used.

To retrieve organization's catalog(s) Get-Catalog cmdlet is used.

 Published     : False  
 Shared      : False  
 Created      : 4/28/2014 2:38:05 PM  
 Org        : HostileCoding  
 Owner       : system  
 VAppTemplateCount : 1  
 MediaCount    : 0  
 ExtensionData   : VMware.VimAutomation.Cloud.Views.AdminCatalog  
 Href       : https://192.168.243.50/api/admin/catalog/873e5007-896d-418b-ae0f-67e9131a1eb6  
 Description    :  
 Id        : urn:vcloud:catalog:873e5007-896d-418b-ae0f-67e9131a1eb6  
 Name       : Catalog1  

In vCloud Director user roles are extremely important because they grant certain capabilities to specific tenants. As you know vCD has five predefined user roles (excluding sysadmin role which is the global role of the user installing/managing the global vCD environment):

• Organization Administrator 
• Catalog Author
• vApp Author 
• vApp User 
• Console Access Only.

By being in one of these groups a tenant can or cannot perform several tasks. To retrieve to which role, with corresponding permissions, each user has been assigned to the Get-CIRole cmdlet is used:

Get-CIRole -User User1

 Name              ReadOnly Rights  
 ----              -------- ------  
 Organization Administrator   False  {Organization: Edit Properties, Orga...  

Then to retrieve detailed infos about a specific user:

Get-CIUser -Name User1

 Href      : https://192.168.243.50/api/admin/user/056c48fd-1b7f-4d48-8da6-81cb53ff0af3  
 StoredVMQuota  : 0  
 StoredVMCount  : 0  
 IM       :  
 DeployedVMQuota : 0  
 DeployedVMCount : 0  
 Phone      :  
 Org       : HostileCoding  
 LdapName    : User1  
 Locked     : False  
 IsLDapUser   : False  
 HasGroupRole  : False  
 External    : False  
 Enabled     : True  
 FullName    : User One  
 Email      : user.one@mycompany.com  
 ExtensionData  : VMware.VimAutomation.Cloud.Views.User  
 Name      : user1  
 Id       : urn:vcloud:user:056c48fd-1b7f-4d48-8da6-81cb53ff0af3  
 Description   :  

This informs us regarding the organization the user belongs, if it is enabled or not, as well as how many VMs has deployed or stored.

To retrieve vApps a user is entitled to access/manage the Get-CIVApp cmdlet is used.

 Href        : https://192.168.243.50/api/vApp/vapp-7591186a-1d3d-4a0c-b392-b2bd7d373210  
 ExtensionData   : VMware.VimAutomation.Cloud.Views.VApp  
 Enabled      : True  
 Status       : PoweredOn  
 SizeGB       : 5  
 CpuCount      : 1  
 MemoryAllocationMB : 256  
 MemoryAllocationGB : 0.25  
 InMaintenanceMode : False  
 Owner       : system  
 Org        : HostileCoding  
 Shared       : False  
 StorageLease    : 30.00:00:00  
 RuntimeLease    : 7.00:00:00  
 Description    :  
 Id         : urn:vcloud:vapp:7591186a-1d3d-4a0c-b392-b2bd7d373210  
 Name        : myFirstCloudvApp  

A vApp is, identically to the ones seen in vSphere, a container for one or more VMs. Here the concept is a little broader since a vApp in vCloud can also contain one or more networks to which the VMs in the vApp are connected to. If you have a look at the previous output several other infos are retrieved like the number of vCPUs, the amount of RAM memory, the power status and both the Storage and Runtime lease expressed in days.

To retrieve all VMs belonging to a specified vApp we use the Get-CIVM cmdlet. In this example only one VM is contained inside myFirstCloudvApp (yes I know, I selected wrong OS during initial VM creation)!

Get-CIVM -vApp myFirstCloudvApp

 ExtensionData  : VMware.VimAutomation.Cloud.Views.Vm  
 Status     : PoweredOn  
 Deleted     : False  
 GuestOsFullName : Red Hat Enterprise Linux 6 (64-bit)  
 CpuCount    : 1  
 MemoryMB    : 256  
 MemoryGB    : 0.25  
 OrgVdc     : VDC-Customer1  
 VApp      : myFirstCloudvApp  
 Description   : This is a simple configuration for Ubuntu Server  
 Href      : https://192.168.243.50/api/vApp/vm-e11d8857-6fa5-4fa1-ab52-b9  
          3c91a23c18  
 Id       : urn:vcloud:vm:e11d8857-6fa5-4fa1-ab52-b93c91a23c18  
 Name      : Ubuntu Minimal  

In the following posts I will provide some scripts to offer some useful capabilities to vCloud tenants.

That's all!!

VMware: Automate the manual deployment of vCloud Agent

While creating provider VDCs in vCloud Director sometimes occurs that not every host is being prepared successfully due to various reasons: something configured incorrectly, cannot place host into maintenance mode, cannot communicate with host, etc. This incapability to correctly dialogue with ESXi hosts leads to the missing deployment of vCloud agent on the hosts belonging to a provider VDC.

The best way to solve this is to fix the underlying problem. Let's be clear: when everything is fine vCloud Director agent deployment works smooth but when something is not the host preparation may become quite a pita. A way to fix this is to proceed with a manual deployment of vCloud agent but, as you reckon, this is quite uncomfortable when dealing with a large number of ESXi hosts.

Today's post goal is to provide a PowerCLI script that allows you to automate the manual process of vCloud agent deployment as well as a mass agent upgrade.

The following script will:

-Connect to a vCenter Server
-Download to your local machine the specified vCloud agent version from vCloud Director virtual machine
-For each host on which you need to install vCloud agent script will:
    -Place host into maintenance mode
    -Enable SSH
    -Check whether vCloud agent is installed or not. If already installed uninstall it first
    -Transfer vCloud agent over to ESXi host using Putty Secure Copy
    -Install vCloud agent
    -Disable SSH
    -Exit maintenance mode
   
Once vCloud agent is successfully installed ESXi host is seen as correctly prepared from vCloud Director.

This is the PowerCLI code. As always you can also find it in my GitHub repository. Automate vCloud Agent Deployment.ps1



Code is quite well commented but let me spend a few words on some cmdlets.

Initial part comprises variable declaration. $FileVcloudAgent is the version of vCloud agent that will be downloaded from vCloud Director virtual machine and later installed on all specified ESXi hosts. In the script I use vcloudagent-esx51-5.1.0-799577.zip file. As name states this version is for ESXi 5.1. If you have different ESXi versions you MUST choose the appropriate ones, like vcloudagent-esx55-5.5.0-1280396.zip if you are using ESXi 5.5 (with vCloud Director 5.5) or vcloudagent-esx50-5.1.0-799574.zip in case of ESXi 5.0, etc.

$puttyScpLocation points to the location of Putty Secure Copy (pscp.exe) that can be downloaded from here and must be placed somewhere on your local machine. Putty Secure Copy is used to copy vCloud agent over to /tmp/ folder of each ESXi host.

Copy-VMGuestFile is a PowerCLI cmdlet used to download specified file from vCloud Director virtual machine to your local machine. -GuestToLocal parameter states that we are downloading files from a VM. Au contraire -LocalToGuest would have been used.

Crucial commands of script above are the VIB uninstall/install ones. To perform a VIB installation on an ESXi host you must use esxcli commands using the following syntax:

 $esx=Get-EsxCli -VMHost <ESXi host on which use esxcli>  

esxcli commands can be executed from PowerCLI by exposing the esxcli functionalities. This is done using:

 $esx=Get-EsxCli -VMHost <ESXi host on which use esxcli>  

and later calling esxcli installation command:

 $esx.software.vib.install("/tmp/$($FileVcloudAgent)", $false, $false, $true, $false, $false)  

On which each parameter has the following meaning:

 Value:vim.EsxCLI.software.vib.install.InstallationResult  
    install(string[] depot, boolean dryrun, boolean force,  
    boolean maintenancemode, boolean noliveinstall, boolean  
    nosigcheck, string proxy, string[] vibname, string[]  
    viburl)  

That's all!!

VMware: run PowerCLI on Android using a PHP back-end

I'm passionate about Android since the beginning, I still remember how cool it was my 7" tablet with Android 1.5 Cupcake the day I bought it about 5 years ago. Since then I spent a good amount of time, mostly during the evenings while studying for my MS in computer engineering, to develop for Android. It's been a couple years since my last Android related project so I decided to come up with a post which brings together two of the things I mostly like: VMware & Android.

After a bit of nostalgia in post introduction let me explain what we are going to do: we are about to create an Android application which allow us to write and run PowerCLI scripts directly from our phone/tablet. This is possible using a back-end PHP page that will receive PowerCLI commands and will run them returning back the output.

PHP back-end will run PowerCLI cmdlets by using shell_exec() function as it was in WebPowerCLI. Android app will be the front-end and will pass commands to the back-end by performing an HTTP Post.

This is just an example, a starting point from which you can develop something more interesting. Back-end URL is coded statically, as well as the Connect-VIServer cmdlet. You could improve this by introducing, for example, the capability for your users to select the back-end URL as well as the customization of Connect-VIServer cmdlet. From a security perspective, especially when used from outside your network, an SSL (possibly heartbleed-free) connection should be adopted in order to protect data transmitted from your Android device to the server.

Let's start by discussing a bit about the back-end PHP page. In order to properly work this web page must be hosted on a Windows IIS web server on which PowerCLI is installed. You can refer to WebPowerCLI instructions in order to setup your Windows server with IIS, PHP & PowerCLI.

The PHP back-end page code is quite simple:



As you can see all the heavy lifting is performed by this instruction:

 $query = shell_exec("$powercli")  

which executes executes PowerCLI and runs the passed commands.

The front-end is simple as well, HTTPPostActivity.java contains all the code while layout design is defined in layout/main.xml file. values/strings.xml contains all text strings used in the app. Using separate files for different tasks is a good practice that enormously increase code readability, this concept is related to MVC which I briefly explained in Dynamic reports using PowerCLI and AngularJS.

This code was written in Eclipse with ADT Plugin.

Download HTTPPostExample from GitHub

The following images depicts how our app will look like:

In HTTPPostActivity.java there are two elements noteworthy: the first is the postData() function which executes an HTTP post to the URL of the back-end PHP page.

This function is called in:

 this.postData("sendpowercli", inputCommandText.toString().replaceAll("#[^;]*", ""));  

where sendpowercli MUST reflect the POST variable expected in PHP page:

 $variable1=$_POST["sendpowercli"];  

while inputCommandText contains the PowerCLI code inserted by the user, accordingly trimmed in order to ignore PowerCLI comments and replacing new lines with ;.

The second element to pay attention to is the AsynchTask, this will execute the HTTP post in background without freezing the user interface and presenting a "loading in progress" pop-up.

 //Asynch Task  
 private class RunPowerCli extends AsyncTask<String, Void, String> {  
      @Override  
      protected String doInBackground(String... params) {  
           inputCommandText = inputText.getText().toString().replaceAll("\\n", ";"); //Every command must be separated using ;  
           this.postData("sendpowercli", inputCommandText.toString().replaceAll("#[^;]*", "")); //Ignore PowerCLI comments  
           return response;  
      }  
      @Override  
      protected void onPostExecute(String result) { //When execution completed set text  
           TextView txt = (TextView) findViewById(R.id.output);  
           txt.setText(response);  
           pd.dismiss();  
      }  
 }  

That's all!!

VMware: Automate OpenStack vApp deployment using PowerCLI

For those who wants to try OpenStack on VMware vSphere without struggling with GIT pulls and manual file edit the OpenStack Team at VMware provides the VOVA, (Vsphere Openstack Virtual Appliance) an Ubuntu virtual machine which comes with OpenStack Havana pre-installed and pre-configured to run on vSphere. To be clear this is not the entire OpenStack's stack, this comprises Nova, Glance, Cinder, and Keystone but according to the official community on VMTN there's the possibility to bring in another stack component like Neutron. This one will  require VMware NSX though.

OpenStack on vSphere requires though some infrastructure configurations in order to work, this is not the simple deploy the ova file and everything works. An initial setup must be performed in order to successfully deploy the VOVA.

Let's start by linking the official OpenStack on vSphere documentation in which you will find all instructions for a correct deployment as well as the link for downloading the OpenStack virtual appliance.

As official documentation states we will work with two different clusters: a management cluster where the VOVA vApp will be deployed and one or more OpenStack clusters. These clusters will be managed by OpenStack to deploy instances in. As best practice DRS will be enabled in both clusters and will be set in fully automated mode.

At least two datastores are also required: one, presented only to ESXi hosts belonging to management cluster, in which VOVA will be deployed and one, or preferably more, presented to all ESXi hosts in the OpenStack clusters that will be used by instances.

Networking-side some changes must be implemented: a new vSwitch with a private br100 PortGroup will be created on hosts in both OpenStack and management cluster. This PortGroup will be used by all OpenStack instances as well as by VOVA that will have NICs associated to different PortGroups: one on the br100 PortGroup forwarding packets received on that interface towards the outside network and vice-versa while the other on classic VM Network PortGroup to communicate with the rest of the network.

This is a logical schema giving an idea on how the environment should be configured:

Since some work is required in order to successfully use OpenStack on vSphere why not to automate its deployment using PowerCLI?

The following script:

-Connects to a vCenter Server
-Creates a Datacenter
-Creates two clusters: a Management and an OpenStack one
-Adds ESXi hosts to both clusters
-Configures ESXi hosts networking creating a vSwitch1 and a br100 PortGroup
-Deploys the OpenStack virtual appliance in one host belonging to the management cluster
-Configures OpenStack virtual appliance editing OVF Environment
-Starts up OpenStack and points user's browser to starting page

Here's how the final result will look like from vCenter:

This is the PowerCLI code, as usual you can find it also in my GitHub repository. Automate OpenStack vApp Deployment.ps1



The code is pretty well commented but some parts requires a further clarification:

 Import-vApp -VMHost $MgmtHosts[0] -Source $SourceFilePath -Datastore $InstallDatastore -DiskStorageFormat $DiskFormat -Force:$true  

imports a vApp in ova or ovf format to a designated ESXi host and datastore. DiskStorageFormat parameter is used to select how the vApp will be deployed in the datastore (Thin, Thick Lazy or Thick Eager).

The following code is used to edit OVF environment properties for the vApp since once deployed it needs to be configured in order to work properly.

These are the properties defined in VOVA:

 <PropertySection>  
    <Property oe:key="vami.DNS.VOVA" oe:value=""/>  
    <Property oe:key="vami.gateway.VOVA" oe:value=""/>  
    <Property oe:key="vami.ip0.VOVA" oe:value=""/>  
    <Property oe:key="vami.netmask0.VOVA" oe:value=""/>  
    <Property oe:key="vm.vmname" oe:value="VOVA"/>  
    <Property oe:key="vmware.cluster_name" oe:value=""/>  
    <Property oe:key="vmware.datacenter_name" oe:value=""/>  
    <Property oe:key="vmware.datastore_regex" oe:value=""/>  
    <Property oe:key="vmware.host_ip" oe:value=""/>  
    <Property oe:key="vmware.host_port" oe:value=""/>  
    <Property oe:key="vmware.password" oe:value=""/>  
    <Property oe:key="vmware.username" oe:value=""/>  
 </PropertySection>  

Credit for the code snippet goes to Alan Renouf .In his article Alan explains how to automate LogInsight vApp deployment by changing OVF environment properties using PowerCLI.

 $VirtualMachineConfigSpec = New-Object VMware.Vim.VirtualMachineConfigSpec  
 $VirtualMachineConfigSpec.vAppConfig = New-Object VMware.Vim.VmConfigSpec  
 $VirtualMachineConfigSpec.vAppConfig.property = New-Object VMware.Vim.VAppPropertySpec[] (x)  
 $VirtualMachineConfigSpec.vAppConfig.property[x] = New-Object VMware.Vim.VAppPropertySpec  
 $VirtualMachineConfigSpec.vAppConfig.property[x].operation = "edit"  
 $VirtualMachineConfigSpec.vAppConfig.property[x].info = New-Object VMware.Vim.VAppPropertyInfo  
 $VirtualMachineConfigSpec.vAppConfig.property[x].info.key = "Integer Key"  
 $VirtualMachineConfigSpec.vAppConfig.property[x].info.value = "Value"  
 $Reconfig = $appVOVA.ExtensionData  
 $Configtask = $Reconfig.ReconfigVM_Task($VirtualMachineConfigSpec)  

After the deployment your browser will be pointed to OpenStack console and you should see something similar to this:

Username is demo while password is vmware.

To create a new instance go to Instances

Launch Instance, select availability zone, instance name, flavor i.e. the "size" of the instance, instance boot source and finally the image to deploy. By default VOVA comprises a Debian image ready to be deployed.

Instance should take a few minutes to start the first time because VOVA will copy Debian image in one OpenStack managed datastore, subsequent deployments will be faster since files are already there.

Root privileges on deployed instances as well as in VOVA console can be accessed using root as username and vmware as password.

That's all!!