Tag Archives: vCNS

Deploying a vShield Edge: “The virtual machine is not supported on the target datastore”

FailedEdgeDeploy02Attempting to deploy a vShield Edge (5.5) via an API call, I was greeted with the following error:

Content as string: <?xml version=”1.0″ encoding=”UTF-8″?>
<error><details>Failed to publish configuration on vShield Edge. Failed to deploy edge
appliance.</details><errorCode>10105</errorCode><rootCauseString>The virtual machine is not supported on the target
datastore.</rootCauseString><moduleName>vShield Edge</moduleName></error>


The API call was the second of two calls to deploy an Edge device into a vSphere Datacenter and Cluster, i.e. one Edge per datacenter, into a specified cluster.

The first Edge was deployed successfully, but not the second. Both clusters were configured in a very similar manner, the only real difference being the name of the datacenter they belonged to. Everything was hosted in a lab based solution using nested ESXi hosts.

My GoogleFu revealed not a lot more than this API reference doc and this description:

The virtual machine is not supported on the target datastore. This fault is thrown by provisioning operations when an attempt is made to create a virtual machine on an unsupported datastore (for example, creating a non-legacy virtual machine on a legacy datastore).

Much troubleshooting ensued before a resolution. Given that it was a lab all, of the ESXi hosts in both vSphere datacenters had access to the same datastores. While not typically a good idea for production, it had been an easy way for me to get the lab up and running. vSphere was quite happy for me to run things like this with VMs in both datacenters on the same datastores. vShield however, was not so happy and this turned out to be the reason it was failing to deploy with “The virtual machine is not supported on the target datastore”.

Reconfiguring the storage so that datastores were limited by datacenter then permitted successful Edge deployment in both sites.


VMworld Europe 2014 – Day 1

The Monday of VMworld Europe is all about the labs for me. Given it is Partner Day and typically quieter around the conference than the rest of the week, I spend as much time in the labs as possible. Even though they are available online I never seem to get round to taking them outside of the conference.

I didn’t need to queue longer than 10 mins for any of the three labs I took which was pretty good. I expect the queues will be a lot longer from Tuesday.



The labs I sat through were first of all VMware NSX Introduction. NSX is one of my key aims this week for finding out more information. I have spent some time on my current project automating vCNS related things so was keen to see how they mapped to NSX. I enjoyed this lab as it gave me good info on the things I already knew about in vCNS and covered the basics of the more network routing related topics.

The standard time you have to complete a lab is 1hr 30 mins. I used the optional feature to extend this by an additional 30 mins and managed to get through it all in good time, without needing to come back to it. Since I was taking it on a day when there wasn’t much else going on, I was quite happy to use 2 hours of my time on this.


The second lab for me was the below. Again, a key learning point for the week is NSX and vCAC integration so I picked up some good info here. I used pretty much the full 2 hours for this lab too.


Thirdly, I took the Infoblox Partner lab. Have done some work with Infoblox in vCO with the generic REST plugin, so was keen to see what the official plugin could offer.


By far and away the most popular lab today was the NSX Introduction lab. This picture was taken early in the day, but the ration was pretty similar later on. By the time 1000 labs in total had been hit around 200 of them had been the NSX lab with Virtual SAN and Virtual Volumes in 2nd and 3rd places respectively.


For this evening’s event, the place to be appeared to be the PernixData party held at a stylish venue in a square in the middle of Barcelona. Plenty of good chat was held with community chums and catching up with those not seen for some time.



Use Headers in a vCO REST Operation

vCenter Orchestrator has a built -in plugin for working with systems that support REST API queries. I’ve used this fairly extensively recently while working with vCNS

Out of the box the plugin will do the majority of the hard work for you, however one thing that isn’t available via the Add a REST operation dialogue is the ability to configure a custom header for the REST query. In the following example I need to add an if-match header to update the App firewall rules for a portgroup, but for a POST method I only have the option to specify the Content type:


Per the vCNS API document I need to be able to send  something like the following

POST https://<vsm-ip>/api/2.0/app/firewall/dvportgroup-28/config –header ‘Content-Type:text/xml’ –header ‘if-match:”1347501121780″‘

So we need to dig a bit deeper. After creating a workflow from the REST Operation we have something like the following:


and in the Scripting task, the following code:


Luckily, (and something I hadn’t noticed before) an example for how to set a header has been added as a standard comment:

//Customize the request here
//request.setHeader("headerName", "headerValue");

So in this example we need to add the following:

request.setHeader("If-Match", generationNumber);

First of all though, we will need to add an input for the generationNumber (you can obtain the generationNumber by first of all querying the current ruleset and looking for the Etag header):


Now we can update the Scripting task:


and we can successfully add extra App Firewall Rules when using this workflow now:



vShield 5.5 API Programming Guide – Corrections


It’s pretty disappointing to need to do this, but recently while working with vCNS / vShield 5.5 and automating it via the REST API I have been making extensive use of the vShield 5.5 API Programming Guide.  On the whole its a decent document with lots of useful examples, without which I would have been struggling.

However, there are numerous mistakes in it, particularly around the URLs required for various API calls. The document doesn’t seem to have been QA’d particularly well before being released and as far as I can see many of these same mistakes are present in the 5.1 document.

Since other people seem to be wasting time finding the same type of issues, I’m documenting those I find as I go on in the hope that at least it should make it easier for people to find what’s wrong, rather than waiting for a communities post response or trial and error like I have been doing.

Those I have discovered so far are below. The documented URL is listed first, the correct one is below it.

Area Title URLs -Documented, Followed By Corrected  Page
List IPsets Created on a Scope GET https://<vsm-ip>/api/2.0/services/ipset/<scope-moref> 31
GET https://<vsm-ip>/api/2.0/services/ipset/scope/<scope-moref>
Add Service to a Scope POST https://<vsm-ip>/api/2.0/services/application/scope/<moref> 41
POST https://<vsm-ip>/api/2.0/services/application/<moref>
Get Details of a Service GET https://<vsm-ip>/api/2.0/services/applicationgroup/<applicationgroup-id> 43
GET https://<vsm-ip>/api/2.0/services/application/<application-id>
Modify Service Details PUT https://<vsm-ip>/api/2.0/services/applicationgroup/<applicationgroup-id> 43
PUT https://<vsm-ip>/api/2.0/services/application/<application-id>
Delete Service from Scope DELETE https://<vsm-ip>/api/2.0/services/applicationgroup/<applicationgroup-id>?force=<true|false> 44
DELETE https://<vsm-ip>/api/2.0/services/application/<applicationid>?force=<true|false>
Virtual Servers
Append virtual server POST https://<vsm-ip>/api/3.0/edges/<edgeId>/loadbalancer/config/virtualserver 136
POST https://<vsm-ip>/api/3.0/edges/<edgeId>/loadbalancer/config/virtualservers
Force Sync Edge Device GET https://<vsm-ip>/api/3.0/edges/<edgeId>?action=forcesync 141

If you have any of your own, please leave them in the comments and I’ll add them to the above.