vCO - VcOptionValue which value type?

Got some tricky task this week: Change the advanced parameter "NFS.MaxVolumes" of a ESX host to 256. First thought was: my post for VcOptionValue on the virtual machine. So I searched for the scripting class and wrote some like this:



var configMgr = myHost.configManager;

for(i in configMgr.advancedOption.queryOptions("NFS.MaxVolumes")){
            System.debug(configMgr.advancedOption.queryOptions("NFS.MaxVolumes")[0].key);
}

var oValues = new Array();
oValues[0] = new VcOptionValue() ;
oValues[0].key = "NFS.MaxVolumes";
oValues[0].value = 256;


try {
            configMgr.advancedOption.updateOptions(oValues);
}catch (e){

           System.log("Could not setAdvanced Settings. Error: " + e);
}



which should be run. But after firing this in vCO there comes an error message like: "wrong parameter" and "internal error". I looked into the vCO logs, the vSphere client and the vpxd.log but all messages didn´t show the exact problem.

After some investigation i found out that the type definition of the value is necessary! So there are some like int, float or long. In my case "long" was the answer. So the code has to look like this:




var configMgr = myHost.configManager;

for(i in configMgr.advancedOption.queryOptions("NFS.MaxVolumes")){
            System.debug(configMgr.advancedOption.queryOptions("NFS.MaxVolumes")[0].key);
}

var oValues = new Array();
oValues[0] = new VcOptionValue() ;
oValues[0].key = "NFS.MaxVolumes";
oValues[0].value_LongValue = 256;


try {
            configMgr.advancedOption.updateOptions(oValues);
}catch (e){

           System.log("Could not setAdvanced Settings. Error: " + e);
}

So, after the next test everything was fine :)

WaveMaker - handling SSL certificates

In the past some people ask for the SSL certificate handling of WaveMaker. This is mostly caused by WebService integration. With my new vCO 5.1 appliance I had the problem again. After generating a new certificate for the vCenter Orchestrator here I connected the WaveMaker and had to learn a hard lesson: no more HTTP API connection with SOAP! Checking the cause in the browser I could see that there is always a HTTPS redirection :)

So I had to import the certificate of the vCenter Orchestrator like this:

sudo keytool -import -alias vco51.vcloud.lab -file /Users/cjohannsen/Desktop/vco51.vcloud.lab -storepass changeit -keystore /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/lib/security/cacerts 

As you can see the WaveMaker uses the JDK certificate store. So I had to export the vCO certificate (i used Firefox) and import it in the certificate store. The store password is originally "changeit". After a WaveMaker restart I tried to connect the https path:

https://vco51.vcloud.lab:8281/vmware-vmo-webcontrol/webservice?wsdl

and everything was fine.

With this its really easy to access the SOAP API. Next post will show how to connect the REST API with WaveMaker :)

vCloud Director - get chain length and consolidate a vCloud:VM

As you may know it isn´t possible to consolidate a VM as an organization administrator. In most environments the customer gets an Org (Cola for example) and can deploy vApps etc. but isn´t able to consolidate a vCloud:VM (i use the vCO syntax for explicit wording).

If you want to provide this function in a customer portal, with WaveMaker for example, you need to check the chain length and when the user decides the consolidate method has to be called.

I build a workflow:

The workflow has three steps: determination of the chain length, user decision to consolidate or not and the consolidate call itself. The first part (getChain script) looks like this:



myVm.updateInternalState();

System.log("VM name: "+myVm.name);

var doc = new XML(myVm.toXml());
default xml namespace = doc.namespace();
var n8 = new Namespace("http://www.vmware.com/vcloud/extension/v1.5");

System.log("ChainLength: "+doc.VCloudExtension.*::VmVimInfo.*::VirtualDisksMaxChainLength);

var chainLength = doc.VCloudExtension.*::VmVimInfo.*::VirtualDisksMaxChainLength;

if(myVm.vmStatus.value != 8){
throw("VM is not powered off!");
} 

As you can see I update the state of "myVM" (vCloud:VM) and setting the variable "chainLength" (number). The chain length is used as external input for the user interaction, so it´s possible to decide based on the count.

After the submission the myVm.consolidate() method is called and the workflows waits for it.

With my host.login() workflow you can combine the Org based login with the consolidation of vCloud:VM´s :)

vCO 5.1 appliance - how-to fix the localhost.localdom certificate

Yesterday I updated my local lab to the brand new vCloud Suite 5.1. The most interesting thing for me was the vCenter Orchestrator appliance and it´s REST API. So after the deployment the appliance came up (I had to disconnect/connect the cd-rom while the certificate was generated) and the typical configuration interface was available.

After some normal tests I had some smaller problems:

1. the logs windows doesn´t show the logs
2. the browser tells me that the ceritifcate isn´t okay

My colleague Christophe Decannini points me in the right direction with the logs problem: the time between appliance and client was different. After changing the time and timezone everything was fine.

The second problem wasn´t this easy to solve. First I created a new certificate with the standard configuration service method:

After that I checked the certificate in my browser and was surprised that the certificate name was localhost.localdom.

A short console test also shows that the common name wasn´t right.

After a few more tests Burke Azbill mentioned his blog article and what should I say... even the linux appliance has the problem (article). So i started the following steps:

1. check for the certificate store

2. delete the old "dunes" ceritficate

3. generate new certificate

4. restart the vCenter Orchestrator appliance

After the restart I checked for the certificate again and everything was okay. Now I can test the new REST API :)

PowerCLI - IP reservation with PowerShell

Sometimes I receive questions which aren´t exactly my skill. In this case I was asked for a "IP management" from a .csv/.txt file to receive an IP address and reserve it. The IP address should be used for a vCloud Director vApp deployment. As a google junkie i searched for a ready-to-use solution but there wasn´t any.

So i decide to build a small script and a text file to play around with. The text file (ip_names.txt) only has three informations, comma separated:

ip address; dns name; state

and looks like this:



127.0.0.1;cjohannsen001;reserved
127.0.0.2;cjohannsen002;free
127.0.0.3;cjohannsen003;reserved
127.0.0.4;cjohannsen004;free
127.0.0.5;cjohannsen005;free
127.0.0.6;cjohannsen006;reserved



The goal was to select an ip address and if the address is chosen it should be reserved by changing the state keyword.

After a few attempts I figure out the following script:



$file = "ip_names.txt"
$Lines = Get-Content -path $file -readcount 0


For($i=0; $i -lt $Lines.Count; $i+=1){


$ip = $Lines[$i].ToString().Split(';')[0].Trim() 
$dns = $Lines[$i].ToString().Split(';')[1].Trim() 
$state = $Lines[$i].ToString().Split(';')[2].Trim() 
  
    if ($state –eq 'free') {
echo $ip "... is free"
$Lines[$i]
$bool = Read-Host "Use IP?"
if($bool -eq "yes"){
$Lines[$i] = $Lines[$i].Replace("free", "reserved")
$Lines | Set-Content -Path $file
echo "IP address:"
$ip
break
}
else{
echo "IP wasn´t chosen."
}
}
}

With this small script you will be able to "select" an IP address ;)

chain length consolidation in vCloud Director - multi-tenancy part 2

Based on the last article I think about a solution to enable vCloud Director organization administrators to consolidate their virtual machines (keep in mind this is only available in the SYSTEM organization) without being the SYSTEM administrator.

So if your customers are administrators in their org they aren´t able to consolidate their VMs and this could cause performance issues.

With the "host.login()" method in the vCloud Director plug-in of vCenter Orchestrator you will be able to authorize organization administrators and identify their organizational vApps and VMs. Because the vCenter Orchestrator is connected as a SYSTEM administrator to the vCloud Director you can call methods like "consolidate" directly.

The most valuable step is to identify the chain length of the VM which isn´t viewable as organization admin. So if you know have identified your VMs you can create an scriptable task like this:



myVm.updateInternalState();


System.log("VM name: "+myVm.name);


var doc = new XML(myVm.toXml());
default xml namespace = doc.namespace();
var n8 = new Namespace("http://www.vmware.com/vcloud/extension/v1.5");


System.log("ChainLength: "+doc.VCloudExtension.*::VmVimInfo.*::VirtualDisksMaxChainLength);


var chainLength = doc.VCloudExtension.*::VmVimInfo.*::VirtualDisksMaxChainLength;


if(myVm.vmStatus.value != 8){
throw("VM is not powered off!");
} 




Please keep in mind that the vm.updateInternalState() method is useful cause the state is sometimes not the same as displayed in vCO. This is also useful for the host.login() method in my last article.


The first step identifies the chain length and the second one checks the state of the VM. In my workflow used a "user interaction" with the chain length as external input to ask if the VM should be consolidate. From a external portal you have to use the "answerWorkflow" method.


When the user decides to consolidate (with seeing the chain length in the decision field) the next scriptable task only has a consolidate call:



var task = myVm.consolidate();



The whole workflow looks like this:



You can control the operation in you vCloud Director, there you will see a "consolidating VM" even if you aren´t a SYSTEM administrator :)

vCD is multi-tenant, vCO is single-tenant, what now?

This week I had a discussion with one of our VSSP customers about the integration of vCloud Director in vCenter Orchestrator. As you might know there ist a plug-in for the vCD available which allows you to configure the vCD connection and make it available in vCO.

Now there is one thing to know about: If you configure the plug-in you will use the SYSTEM organization to have all other organizations available. If you connect to the vCO with the SOAP interface (with WaveMaker for example) the users will have full access to the vCD and not only to their organization.

Because of the user and role management in vCloud Director you will be limited in some functions. As example: There is no way to "consolidate" a VM even if you can see the chain length in their properties. This is limited to the provider administrator role.

So what´s the solution?

You can insert all organizations as new vCD connections in the vCD plug-in and as a vCO admin you are able to consolidate... but this isn´t really slick. The other was is to "authenticate" users with their organization and limit their access to their vApps/VMs.

After some attempts i designed a workflow like this:

IN-Parameter:

• org (string)
• user (string)
• pass (string)

IN-Attributes:

• url (string)

which were easy to fill from a web portal. With these parameters you are able to use the VclHost.login() method like this:

VclHostManager.setRuntimeCredentials(user, pass); 

var host = VclHostManager.createHost(); 

host.url = url; 

host.organization = org; 

host.sessionMode = VclHostSessionMode.PER_USER_SESSION; 

host.enabled = true; 

host.login(); 

Now you are "logged" in with the user and the matching org. A way to verify this is to check for the organizations:

var Organizations = host.getOrganizations(); 

for (i in Organizations){

    System.log("Organization: "+Organizations[i].name);

}


As you can see you will only receive the organizations of the logged in user :)

In my test environment it looks like this:

Now you will be able to get the vApps and Vms of the organization and do some magic with them. I will post some further steps (chain length, WaveMaker portal) later... cause I´m a consultant... in a hotel... with some beer... and only a notebook :)