vCloud director – running MAC OS X and Windows VM in same vApp.

Recently we installed in Mac Pro 6,1 hardware and provided MAC OS X virtual machines to our vCloud director environment.

This was configured in a separate cluster in vCenter server which provides all the regular capabilities like HA, DRS and vMotion which is great. Also created a separate storage cluster and assigned a new MAC storage profile to this cluster which was made available within vCD.

MAC OS X templates was created and added to catalog with storage set to pre-provision on default storage profile create for MAC cluster.

Problem: 

In vCloud director a new Provider VDC was created and linked to the new vCenter server cluster.
Within the existing Organizations we created an additional virtual datacenter with MAC provider VDC selected.  This created new resource pool in the cluster.

The users where now able to deploy MAC OS templates to this VDC, however a request came back quickly that users need to deploy both MAC OS X and Windows VM within the same vApp.

Troubleshooting: 

The configuration as explained above obviously does not allow for this situation since during deployment of vApp you can only select a single VDC to deploy too as well for adding a VM you can only specify a single storage Policy, which will also be the one assigned to vApp’s VDC .  So all the VMs would need to run on the Apple hardware cluster which is not idea.

Solution:

Solution was pretty simple and can be accomplished by merging your provider VDC’s which was introduced in vCloud director 5.1.1.

  1. Login to vCloud director as system admin.
  2. Select Manage & Monitor
  3. Under Cloud resources select Provider VDCs
  4. Right click the MAC provider VDC and select Merge
  5. Select the Provider VDC that you want this merge with.
  6. After completion you will now see your Provider VDC has  additional resource pool, datastores and ORG VDCs
  7. I then went ahead and deleted the VDC I initially created for the MAC deployments since only need the original VDC.
Now when you deploy a vApp select the existing VDC which contains the MAC Provider VDC and storage profile.  Same can be accomplish for deploying VM within a vApp.

vCloud 5.5.1: Create new storage policy, add storage, migrate vApps.

We recently purchased new storage so the new datastores had to be added to vCloud director, and all the vApps migrated over.  There are many ways to go about doing this but the best solution I found was to create a new storage cluster and put all datastores in it and also create a new storage policy and profile.  I have been told it is also possible to just perform a storage vmotion on the VM’s but i had mixed results with this approach.  Here is my information which I hope might be useful to someone.

In Vcenter server:
  1. Create tag category (I called mine “storage policies” to keep it simple”, but description can also be used to describe the function)
  2. Create tag and add to category
  3. Open VM storage policies
    1. Create new VM storage policy
    2. Select vCenter
    3. Enter a policy name
    4. Provide description
    5. Add tag-based rule and assign newly create tag from tag category.
  4. I ALWAYS FORGET to enable the policy so here is not to you doing the same 🙂
    1. select the new policy name
    2. 2nd icon from left is “Enable VM storage policies per compute resource.
  1. Assign the newly created tag to datastore cluster
  2. Assign the newly created tag to each datastore within the cluster.

In vCloud director:
  1. Under Manage & Monitor tab select vCenters from vSphere resources.
  2. Right click the vCenter server name and select  “refresh storage policies
After you get the storage profile to show in storage policies you have to assign it:
  1. Go to Provider VDC and open it
  2. Select storage policies tab
  3. Add new storage policy! 
  4. There is a BUG in 5.5.1 which does not refresh or show the storage policy and an outage is actually necessary to clean up the database with a script (not very nice but works)
  1. Go to Organizations and open the one which will be using the new storage
  2. Select Virtual datacenter tab
  3. Select Storage policies tab
  4. Add the new storage policy
  5. If you want the new policy to be the default – Right click the new storage policy and select “Set as default”

Migrating vAPPS to new storage profile:

  • The best method I found was to shutdown the vAPP and right click select “move to” and then each individual VM select the new storage policy.
  • You can also do this with a powered on VM and go to properties and change the storage polic

vCloud Director: Error on provider VDC "No datastores accessible to VDC "

This normally happens when a new datastore is added to the storage cluster which is associate to a storage policy for the vCloud Director Organization.  The rule-set (storage capability) was not properly set to the datastore before it was added to the datastore cluster.

All the datastores, datastore clusters and policies disappear and you get the following errors:

Error on provider VDC:
No datastores accessible to VDC

On Provider VDC storage policies tab:
This storage policy is not backed by any usable datastores accessible from this VDC.
There is no usable datastore accessible from this VDC that supports this storage policy. Ensure that this storage policy is backed by at least one datastore in vCenter Server, this datastore is enabled in vCloud Director, and the datastore(s) are accessible by the hosts in the clusters used by this VDC.

Solution:

Verified that all the datastores in the datastore cluster have the storage capability (Tag) assigned which is associated to the provider VDC.

Check Compliance of the VM Storage profile in vSphere Web client

  • On Home page, select Vm Storage Policies.
  • Right click the storage policy and select “Check compliance”
  • Select the VM Storage Policy
  • Verify everything compliant
  • Select Monitor tab
  • Select Matching Resources
  • Verify that the datastore cluster is showing up as well as all the datastores
Refresh storage policies for vCenter on vCloud Director System.

  • In vCloud Director, under vSphere Resources select vCenters.
  • Right click on the vCenter name and select “Refresh Storage Policies”

vCloud director 5.5: Catalogs problem #3 – Assigning catalog media files to different VDC within an ORG?

We have a public catalog which is shared to all ORGs within vCloud.  This also contains some ISO media files for users to mount to cdrom of virtual machines.
However in order for a user to make use of a media file from a public catalog, that media file firstly needs to be copy to the local catalog of that ORG.

Within this ORG we have multiple vDCs.  This is where things get interesting.

Scenario:

When a vAPP is deployed from catalog you assign this vAPP to a specific vDC.
When you then try to mount an ISO from the local catalog media files, you are unable to do so since this media file is associate to a different vDC…mmm

Troubleshooting:

I believe the problem lies with how the Catalogs are done in 5.5.  When creating or copying files into a Catalog, there is no method to accurately control where the item will be stored. This is more critical when there are multiple Org vDCs, and a file could be placed in an Org vDC to which the file is not intended for.

This is a departure from vCloud Director 5.1, where importing media allowed you to select a specific Organization vDC. Even when you could select a vDC, you still needed to have the ISO image in the vDC where the VM resides to be allowed to insert it.

I had a lot remote sessions and discussions with support on this issue since we could not find a way to assign a media file to specific VDC.

Workarounds:

Option 1 –  Temporarily disable storage profiles before doing an ISO import. This would eliminate certain vDCs as an option, and force the selection process to go to the remaining vDC.  this would be my recommendation.

Option 2 – Set the catalog to use a specific Storage Profile, from the desired Organization vDC and import the media again. This should send the imported files to the correct ORG vDC. You will need to import Media files multiple times to accomplish this.  This only possible if you have multiple storage profiles which I currently do not have.

Option 3 – Have a catalog specific to an individual ORG vDC, name the catalog relative to the ORG vDC, and select the Storage Class/Profile from the same ORG vDC. This means that any ISOs will be sent up to the correct vDC when you import to a given catalog.  On this option here are the steps to setup more catalog for more than one vDC:
1. Create a “master” catalog in the ORG on the Storage Profile vDC A
2. Publish the Catalog created in Step 1 externally
3. Create a “slave” catalog in the ORG on the Storage Profile vDC B, and have this catalog sync from the catalog created in step 1.
4. Repeat this to have Catalog C on Storage Profile C, and sync to Catalog A.
5. Whenever you add a new ISO image to the Master Catalog, it will automatically update the others in 24 hours or when a sync is requested.

vCloud director 5.5: Catalogs problem #2 – Error mounting catalog media ISO files to CDROM – "This media type is incorrect. Media type ISO was expected." (known issue)

Catalogs has had quiet a big revamp in vCloud 5.5 with some enhancements.
This can be read in the “whats’s new” pdf:
http://www.vmware.com/files/pdf/products/vCloud/Whats-New-VMware-vCloud-Director-55-Technical-Whitepaper.pdf

We have a public catalog which is shared to all ORGs within vCloud.  This also contains some ISO media files for users to mount to cdrom of virtual machines.
However in order for a user to make use of a media file from a public catalog, that media file firstly needs to be copy to the local catalog of that ORG.

Problem:

A users copies the media ISO file to local catalog however the file is not copied over correctly.
When users tries to attach the newly copied file from media to CDROM, the following error is observed:
“This media type is incorrect. Media type ISO was expected.”
Troubleshooting:

The original media file for public catalog I am able to mount to CDROM on all VM’s within that catalog.
Once that same media file is copied to local catalog I experienced the problem.
When I uploaded the same media ISO file directly to users catalog I was able to mount the file.
Solution:
No solution as of yet but workaround is to update the tables directly in database.
I just went ahead and uploaded the needed ISO files directly to the local ORGs catalog media files.
I was also able to locate the knowledge base article for the issue mounting ISOs after copying them between catalogs. This article includes the required process on the Database side to correct the ISO/Media bits for the catalog items.

vCloud director 5.5: Catalogs problem #1 – browser crashes on "copy to catalog" (resolved)

Catalogs has had quiet a big revamp in vCloud 5.5 with some enhancements.
This can be read in the “whats’s new” pdf:
http://www.vmware.com/files/pdf/products/vCloud/Whats-New-VMware-vCloud-Director-55-Technical-Whitepaper.pdf

We have a public catalog which is shared to all ORGs within vCloud.  This also contains some ISO media files for users to mount to cdrom of virtual machines.
However in order for a user to make use of a media file from a public catalog, that media file firstly needs to be copy to the local catalog of that ORG.

Problem:

When a user log in directly to their respective ORG
Select the public catalog and go to media tab
Right click on media file select to “copy to catalog”
The browser crashes and restarts without any error messages.

Troubleshoot:

This was tested on MAC and Windows with each of the following browsers including Chrome, Firefox and Internet explorer.
Same problem appears when logged in as ORG or system admin.

However it works fine when I login as system admin to main vCloud Director login page.  Only seems to crash browser when logged in direclty to any ORG site.

Solution:

Do not share the catalog with the radio button “all organizations”, but rather select all the ORGs individually from the list.

I do not experience the same results as listed the following KB but same solution solves both problems:
http://kb.vmware.com/kb/2063431

vCloud Director 5.5 – Replace current self-signed certificates with signed certificates

Initially I had very little time to get vCloud Director up and and running and just created self signed certificates.
After upgrading from vCloud 5.1 to 5.5, we found a known problem with VMware where MAC desktops cannot access VM console when using self-signed certificates.
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2058496

This provided the perfect opportunity to replacing initial self signed certificates with newly created signed certificates. (internal root CA server)

Prerequisites:
SSH to vCloud director:

  • verify ip addresses used for vcloud  (ifconfig -a)
  • run “nslookup ” to identify the FQDN for both http and consoleproxy IP address.  This will also verify that reverse lookup is working correct.

Example:
10.30.15.100 (http)                      vcloud.company.corp
10.30.15.101 (console proxy)       vcloudcp.company.corp

Some considerations before creating new certificates:

  • I already have a Java keystore file /certs/certificates.ks which is currently configured for the self signed certificates. I decided to create a new Java keystore file called “sslcertificates.ks”.  This is not necessary but I wanted to keep the files easily distinguishable.
  • The new Java keystore file i moved to a new folder called /sslcerts/.  This again is not necessary can can keep in original folder or create different one.
  • You can create the new certificates and CSR while vCloud services are running.  You however need to shutdown the vCloud services before you run the configuration script.  Outage required during this short period.


Steps:

  1. SSH to vcloud director (we currently run vcloud on RHEL)
  2. Change folder /opt/vmware/vcloud-director/jre/bin/
  3. Run command to create new keystore file for HTTP:
    • # keytool -keystore sslcertificates.ks -storetype JCEKS -storepass ******* -genkey -keyalg RSA -alias http
      • Keytool utility will prompt for responses to several question. Replace the example input in italics with the information relevant to your environment:
      • What is your first and last name? [Unknown]:                         vcloud.airwatch.corp
      • What is the name of your organizational unit? [Unknown]:       vCloud
      • What is the name of your organization? [Unknown]:                Company
      • What is the name of your City or Locality? [Unknown]:            City
      • What is the name of your State or Province? [Unknown]:         State
      • What is the two-letter country code for this unit? [Unknown]:   US
      • Enter password for http or select option for same password as in command
  4. Run command to obtain CSR for HTTP service:
    • # keytool –keystore sslcertificates.ks –storetype JCEKS –storepass ******* –certreq –alias http –file http.csr
      • This creates a file called the http.csr
  5. Run command to create new keystore file for Console Proxy:
    • # keytool –keystore sslcertificates.ks –storetype JCEKS –storepass ******* –genkey –keyalg RSA –alias consoleproxy
      • Keytool utility will prompt for responses to several question. Replace the example input in italics with the information relevant to your environment:
      • What is your first and last name? [Unknown]:                         vcloudcp.airwatch.corp
      • What is the name of your organizational unit? [Unknown]:       vCloud
      • What is the name of your organization? [Unknown]:                Company
      • What is the name of your City or Locality? [Unknown]:            City
      • What is the name of your State or Province? [Unknown]:         State
      • What is the two-letter country code for this unit? [Unknown]:   US
      • Enter password for http or select option for same password as in command
  6. Run command to obtain CSR for Console Proxy service:
    • # keytool –keystore sslcertificates.ks –storetype JCEKS –storepass ******* –certreq –alias consoleproxy –file consoleproxy.csr
      • This creates a file called the consoleproxy.csr
  7. Copy the http.csr and consoleproxy.csr files that were just create to your local machine. I use an appliciation called WinSCP.
  8. Go to Windows CA certificate server website “https:///certsrv/” and perform following tasks for both the http and consoleproxy CSRs:
    • request certificate
    • advanced certificate request
    • Submit a certificate request by using a base-64-encoded CMC or PKCS #10 file, or submit a renewal request by using a base-64-encoded PKCS #7 file.
    • Open the csr file and copy/paste the text into field.
    • Select certificate template = “Web Server”
    • Submit
    • Select “Base 64 encoded”
    • Download certificate, which will provide a certnew.cer file.
    • Rename the file to be specific for example “_certnew.cer”
  9. Lastly download the root CA certificate.
  10. Copy all 3 certificates to vcloud server and import them into the keystore with following commands:
    • Import the root certificate:
      • # keytool -storetype JCEKS -storepass ******* -keystore sslcertificates.ks -import -alias root -file root_certnew.cer
    • Import the http service certificate:
      • # keytool -storetype JCEKS -storepass ******* -keystore sslcertificates.ks -import -alias http -file http_certnew.cer
    • Import the console proxy service certificate:
      • # keytool -storetype JCEKS -storepass ******* -keystore sslcertificates.ks -import -alias consoleproxy -file console_certnew.cer
  11. To verify that all the certificates are imported, list the contents of the keystore file.
    • # keytool -storetype JCEKS -storepass ******* -keystore sslcertificates.ks -list
  12. Move the certifcate.ks file to new folder:  /sslcerts/sslcertificates.ks
    • “mv /opt/vmware/vcloud-director/jre/bin/sslcertificates.ks /sslcerts/”
  13. Now configure vCloud Director to use the new SSL certificates:
    1. Stop vcloud services “service vmware-vcd stop”
    2. Run following command:
      1. # opt/vmware/vcloud-director/bin/configure
        1. Provide the path to the keystore file  /sslcerts/sslcertificates.ks
        2. Enter passwords
        3. Yes to start the vCloud services.

Now your vCloud should be using newly created certificates.