• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar

virtuallyGhetto

  • About
  • Privacy
  • VMware Cloud
  • Home Lab
  • Nested Virtualization
  • Automation
    • VMware Kickstart
    • VMware API/SDK/CLI
    • VMware vMA/VIMA
    • VMware OVF / OVFTOOL
  • Apple Mac
  • VCSA
  • VSAN

vcloud director

Quick Tip – Using ovftool to connect to vCloud Director behind a 2-Factor Authentication portal

06/08/2015 by William Lam 2 Comments

A couple of months back I ran into an issue while trying to upload a couple of files to VMware's internal OneCloud environment which uses vCloud Director. The issue that I encountered was that our OneCloud environment no longer supported basic username/password authentication, which I hoping to automate using ovftool. Instead, it is now front-ended with VMware Application Manager which requires 2-Factor Authentication (2FA) and once authenticated, a SAML token is then passed to vCloud Director which then automatically logs you in.

ovftool-vcloud-director-SAML-authentication-0
The problem with this is that ovftool can not be used to directly login to vCloud Director as it does not have support for 2FA, which makes automating operations against our OneCloud environment pretty difficult. After spending a few days looking for an alternative and not having any luck, my last hope was to reach out to the ovftool developers to see if they had seen this before.

After a few email exchanges, although ovftool does not support 2FA, you can however get this to work using session ticket authetnication which it does support using either the --I:sourceSessionTicket or --l:targetSessionTicket option. To get more details on these options, you can run the following ovftool command:

ovftool --help integration

In order to use this session ticket mechanism to authenticate into a 2FA environment, you must first login manually using a web browser. Once you have successfully logged in, you will need to either use browser developer tool or something like Firebug to record the authenticated vCloud Director cookie which will then be passed to ovftool.

In this example, I am using Chrome and you can find the Developer Tools by going to Options->More Tools->Developer Tools. Next, refresh the webpage so you are able to see the web requests between your browser and vCloud Director. Now navigate to Network->Cookies option and select any one of the requests to the left of the screen such as "amf".

ovftool-vcloud-director-SAML-authentication1
What you will be looking for is the value to the cookie named "vcloud_session_id" which is is the authenticated session that we will use to provide to ovftool. Once you have that value, you can then specify the connection to ovftool using the following:

ovftool --I:targetSessionTicket=[VCLOUD_SESSION_ID_VALUE] vcloud://...

I had known that ovftool supported session based tickets, however I did not realize it could be used to authenticate behind a 2FA solution like VMware Application Manager. For folks interested in using ovftool and session based tickets directly with vSphere, check out this awesome post by my good friend Jake Robinson who demonstrates this using PowerCLI, ovftool and the AcquireCloneTicket() vSphere API method.

Share this...
  • Twitter
  • Facebook
  • Linkedin
  • Reddit
  • Pinterest

Filed Under: Automation, OVFTool Tagged With: ovftool, SAML, vcd, vcloud director, vSphere API

Creating your own 3rd Party Content Library for vSphere 6.0 & vCloud Director 5.x

06/02/2015 by William Lam 18 Comments

If you recall a few weeks back, I had shared a custom vGhetto Content Library that I had created that contains a collection of my Nested ESXi and VSAN OVF Templates that anyone with a vSphere 6.0 or vCloud Director 5.x environment could subscribed to. This custom Content Library is also known as a 3rd Party Content Library and is one of the capabilities that I am most excited about with the new Content Library feature in vSphere 6.0. The reason I think this is such a cool capability is that I believe it opens up a wide range of use cases not only for our customers but also for our partner eco-systems enabling ease of content management and content distribution for VMware customers.

Just imagine, a vendor who might be providing Virtual Appliances (OVF/OVA), ISOs, VIBs, patches, workflows, blueprints, scripts, etc. can host a 3rd Party Content Library and as a customer you can easily subscribe to a particular repository. Once subscribed, you can either have the content automatically downloaded or synchronized on-demand. In fact, customers can also create their own 3rd party Content Library and distribute their own content within their own organization (local and remote sites) and even be able to share it with others in the VMware community.

Before I jump into the process of creating your own 3rd Party Content Library, I wanted to quickly go over the different options for publishing and subscribing to a Content Library. Below is a diagram to help you visualize the different options you have for publisher and subscriber sources.

vsphere-6.0-class-content-library-as-a-service
Here is the same information as shown in the diagram but in a table format:

Publisher Subscriber
vCenter Server vCenter Server
vCloud Director vCenter Server
3rd Party vCenter Server
3rd Party vCloud Director

Note1: Although the diagram technically shows a 5th scenario where a vCenter Server is the publisher and vCloud Director is the Subscriber, this particular flow is not entirely functional at the moment. Though it will work, it will only allow you to sync non-VM Templates and a different version of the script would be needed. This is a known issue and hopefully it will be resolved in a future update within vCloud Director.

Note2: For 2nd scenario where vCloud Director is a Publisher and vCenter Server is a Subscriber, On-Demand synchronization and overriding an existing OVF Library is currently not supported.

Here is the high level workflow for creating your own 3rd Party Content Library:

  1. Create directory structure layout for your content
  2. Create the JSON metadata index
  3. Publish the 3rd Party Content Library using HTTP(s)
  4. (Optional) Periodically update the JSON metadata index on new or updated content

Step 1 - Here is an example of what your directory structure layout should look like:

creating-third-party-content-library-0
Step 2 - To assist with the JSON metadata indexing, Eric Cao, one of the Content Library Engineers was kind enough to provide the following Python script called make_vcsp_2015.py which you will need to download onto a system which has the Python interpreter running

UPDATE (05/29/17) - Thanks to Eric, the script now supports both Python2/3 as well as a new 4th optional command-line argument for performing md5check (Default: true)

Step 3 - The make_vcsp_2015.py script accepts two arguments: the first is the display name of the Content Library and the second argument is the path to the root directory of your Content Library. Here is an example:

python make_vcsp_2015.py vghetto-content-library /Users/lamw/desktop/vghetto-content-library

Once the script has finished building the metadata index, we can now take a look at our content and you will notice some additional files that have been added to your Content Library directory as seen in the screenshot below:

creating-third-party-content-library-1
You will notice two new files at the root directory of your 3rd Party Content Library. The first is the items.json which provides reference to all the files within the library and you will see that each subsequent directory will also contain an individual item.json file describing the content within the local directories. The lib.json is the 3rd Party Content Library endpoint and is what you will be specify when subscribing to a 3rd Party Content Catalog and by providing the absolute URL to this file when setting up a new Content Library.

Step 4 - To publish the 3rd Party Content Library, you just need to host the content somewhere that supports HTTP(s), this can be as simple as using a regular Web Server to something like an Object Store such as Amazon S3.

Note: If you plan to use a non-traditional Web Server for hosting your 3rd Party Content, ensure that the root URL is the same for accessing all files and can not change. For example, you will not be able to host a 3rd Party Content Library using Dropbox as the root URL changes for each and every file.

Step 5 (Optional)- Periodically you will most likely want to add new content and files to your 3rd Party Content Library and as part of that process you will also need to update the metadata index. You can easily do so by re-running the make_vcsp_2015.py script against your existing 3rd Party Content Library. The script will only generate new metadata index for files that have been newly added and for any changes to existing files, the appropriate metadata files will only updated.

As you can see the process in creating and publishing a 3rd Party Content Library is pretty straight forward and simple. I hope to see more of our partners start to publish their own 3rd Party Content Libraries, I think it would be extremely beneficial for VMware customers and I look forward to hearing about them :). If you have created your own 3rd Party Content Library and would like to share the details, feel free to leave a comment and I will be aggregating a list below so that you can easily find them all in one place.

Published 3rd Party Content Libraries

Author Library Content Link
William Lam Nested ESXi & VSAN OVF Templates Subscribe to vGhetto Nested ESXi Template Content Library in vSphere 6.0
Alan Renouf Some sample OVF/OVAs Subscribe to Alan's Content Library in vSphere 6.0
Share this...
  • Twitter
  • Facebook
  • Linkedin
  • Reddit
  • Pinterest

Filed Under: vSphere 6.0 Tagged With: content library, vcd, vcloud director, vSphere 6.0

How to deploy vSphere 6.0 (VCSA & ESXi) on vCloud Director and vCloud Air?

04/27/2015 by William Lam 13 Comments

In case you missed the awesome news last Friday, George Kobar who works over in the vCloud Air team shared a really cool solution in which he demonstrates how to efficiently setup Nested ESXi running in vCloud Air which includes support for inner-vm guest communication without requiring Promiscuous Mode. Nested ESXi has been possible on vCloud Air for quite some time, in fact when I was first granted access I had to try it out myself and had written about it here. The great thing about vCloud Air is that it runs directly on vSphere which means you will get all the added benefits of the underlying vSphere platform including things like VHV (Virtual Hardware Assisted-Virtualization) to ensure that your Nested ESXi VM and its virutal workloads runs as efficiently and as performant as possible. If you are new to vCloud Air, I would recommend checking out this tutorial here which goes into some of the basic operations.

Given the updated news regarding Nested ESXi on vCloud Air, I am sure many of you are excited to try out this new trick for those requiring inner-vm guest communication. I figured most of you will be interested in trying out vSphere 6.0, especially with some of the new capabilities like SMP-FT and VSAN 6.0 which runs perfectly fine in a Nested ESXi environment for demo and learning purposes as shown here and here. I thought I would put together a quick guide on how to setup both Nested ESXi 6.0 as well as the new VCSA 6.0 (which does have a few minor caveats but can definitely run in vCloud Director and vCloud Air environment).

nested-esxi-6.0-vcloud-air
vcsa--6.0-vcloud-air
Disclaimer: The usual caveat ... Nested ESXi is not officially supported by VMware

ESXi 6.0

There is no version of vCloud Director for the Enterprise that supports vSphere 6.0 which means there is no direct support for the latest virtual hardware release which is 11 or support for ESXi 6.x guestOS type. This is also true for vCloud Air which is currently running on vSphere 5.5 and because of this reason, you will need to upload a VM that has been configured with ESXi 5.x as the guestOS type when looking to install ESXi 6.0. Once vCloud Air supports vSphere 6.0, then you can upload a VM that has been created with the ESXi 6.x guestOS type.

The easiest way to create Nested ESXi VM in a vCloud Director or vCloud Air environment is to simply import a VM that has already been configured with ESXi guestOS type (this does not need to be an already installed image). To help expedite the deployment of Nested ESXi in vCloud Air, I have built several Nested ESXi OVF Templates that that you can use. You will also need to upload an ESXi 6.0 ISO or whichever version of ESXi you plan on running since both ESX(i) 4.x and 5.x is possible.

VCSA 6.0

One of the challenges I came across when testing the new VCSA 6.0 in a vCloud Director based environment which also affect vCloud Air is that they do not support a few capabilities within the OVF specification, namely Deployment Options. Due to this limitation and few others, we can not directly import the VCSA 6.0 OVA into vCloud Director. Luckily, there is a workaround which I had looked into a few months before the GA of vSphere 6.0 and below are the steps to import a VCSA 6.0 OVA into a vCloud Director environment. If you are looking to run VCSA 5.5, then you can directly import the OVA without going through these steps.

Step 1 - Download and extract the contents of the VCSA 6.0 ISO (Build 2656757 was  used)

Step 2 - Convert VCSA 6.0 OVA located in vcsa/vmware-vcsa into an OVF by either using ovftool, tar or a tool like 7zip.

ovftool --sourceType=OVA vmware-vcsa vmware-vcsa.ovf

Next, you will need to make several modifications to the OVF file. I do have to warn you, there are a few tweaks and I highly recommend that you use the OVF templates that I have already created for you. Make sure to also delete the .mf (manifest file) since you are making changes to the OVF else the OVF validation will throw an error because the files have been modified.

To save you some time, pain and troubles, I have pre-created the following 3 OVFs (based on vSphere 6.0 GA release of VCSA 6.0) which contains all the modifications mentioned in Step 3 which you can download and then jump to Step 4:

  • VCSA 6.0 Embedded Tiny OVF
  • VCSA 6.0 vCenter Server Management Node Tiny ONLY OVF
  • VCSA 6.0 Platform Services Controller Node Tiny ONLY OVF

Step 3 - The first is to locate the "References" tag located at the top of the OVF file and remove the line containing the RPM reference. At the end it should look something like the following:

1
2
3
4
5
6
  <References>
    <ovf:File ovf:href="VMware-vCenter-Server-Appliance-6.0.0.5100-2656759_OVF10-file1.json" ovf:id="layout.json_id" ovf:size="5756"/>
    <File ovf:href="VMware-vCenter-Server-Appliance-6.0.0.5100-2656759_OVF10-disk1.vmdk" ovf:id="VMware-vCenter-Server-Appliance-6.0.0.5100-2656759-system.vmdk_id" ovf:size="524469248"/>
    <File ovf:href="VMware-vCenter-Server-Appliance-6.0.0.5100-2656759_OVF10-disk2.vmdk" ovf:id="VMware-vCenter-Server-Appliance-6.0.0.5100-2656759-cloud-components.vmdk_id" ovf:size="1369250304"/>
    <File ovf:href="VMware-vCenter-Server-Appliance-6.0.0.5100-2656759_OVF10-disk3.vmdk" ovf:id="VMware-vCenter-Server-Appliance-6.0.0.5100-2656759-swap.vmdk_id" ovf:size="74240"/>
  </References>

In addition, depending on the method you took to convert the OVA to an OVF, you may also need to rename the json and disk file names located in this section to match the extracted contents.

The second is to delete the following section from the OVF that starts with MigrationUpgradeRequisitesSection:

1
2
3
4
<vmw:MigrationUpgradeRequisitesSection ovf:required="false">
<Info>Files necessary for migration-based upgrade.</Info>
<vmw:Requisite ovf:fileRef="VMware-vCenter-Server-Appliance-6.0.0.5110-2656759-upgrade-requirements.rpm_id" vmw:purpose="requirements"/>
</vmw:MigrationUpgradeRequisitesSection>

The fourth step is to specify the deployment option type that you wish to use. VCSA 6.0 supports the following: embedded, infrastructure (PSC) and management (VC). You will need to locate the following line containing guestinfo.cis.deployment.node.type and set the value property to one of the three options.

1
<Property ovf:key="guestinfo.cis.deployment.node.type" ovf:type="string" ovf:userConfigurable="false" ovf:value="infrastructure">

The fifth and final step is to specify the deployment size that you wish use for your VCSA, here are nine different supported options:

  • Embedded
    • tiny
    • small
    • medium
    • large
  • vCenter Server Management Node (only)
    • management-tiny
    • management-small
    • management-medium
    • management-large
  • Platform Services Controller Node (only)
    • infrastructure

Since both vCloud Director and vCloud Air does not support the Deployment Option OVF capability, you will need to specify the deployment you wish to use. Locate the DeploymentOptionSection and the first entry where it shows "default=true", you will need to change the id to match one of the entries show above. For example, if you wanted an Embedded VCSA deployment using the tiny size, you would specify "tiny" in the id field.

1
2
3
  <DeploymentOptionSection>
    <Info>List of profiles</Info>
    <Configuration ovf:default="true" ovf:id="tiny">

Once you have selected the type of deployment, you will also need to remove ALL entries referencing the other deployment types else it will always deploy an Embedded deployment.

Note: I would like to give a big shout-out to Doug Baer who works over in the VMware HOL team, he actually discovered the initial issue with the Deployment Options and found the workaround by removing the other disk references. If not, you would end up needing ~2TB of storage as VCD tries to aggregate all nine deployments into one! When I had initially worked out the steps to deploy a VCSA 6.0, I had only used the Embedded deployment option.

Step 4 - Lastly, you will need to change the "capacity" property as seen below from 1303 to 1306 due to a known vCloud Air issue documented in KB2094271

1
<Disk ovf:capacity="1303" ovf:capacityAllocationUnits="byte * 2^20" ovf:diskId="cloudcomponents" ovf:fileRef="VMware-vCenter-Server-Appliance-6.0.0.5110-2656759-cloud-components.vmdk_id" ovf:format="http://www.vmware.com/interfaces/specifications/vmdk.html#streamOptimized" ovf:populatedSize="1365573632"/>

Step 5 - You are now ready to upload your VCSA 6.0 OVF to your vCloud Director or vCloud Air environment.

Note: For vCloud Air, you will need to use the "Manage in vCloud Director" link to upload the OVF as the vCloud Air interface does not support direct OVA/OVF uploads.

Step 6 - When you are are ready to deploy your VCSA, one very important step that you will need to do is to edit a few of the OVF properties in the VM before powering it on. If you power on the VCSA before performing this step, the system will need to be deleted and re-deployed as the OVF properties are only read in on the initial first boot which is required for proper configuration.

  • Make sure to disable guest customization, to do so right click on the VM and select Guest OS Customization and uncheck "Enable guest customization"
  • To edit the OVF properties, right click on the VM and select Properties. Click on Guest Properties and you will ONLY be editing the following three sections

Networking Configuration

vcsa-6.0-networking-configurations
System Configuration

vcsa-6.0-system-configurations
SSO Configuration

vcsa-6.0-sso-configuration
For an Embedded Configuration, you will need to edit the following (below is an example of the data input):

Host Network IP Address: 192.168.110.100
Host Network IP Address Family: ipv4
Host Network DNS Servers: 192.168.110.10
Host Network Default Gateway: 192.168.110.1
Host Network Mode: static
Host Network Identity: vc-01a.corp.local
Host Network Prefix: 24
Tools-based Time Synchronization Enable: check OR NTP Servers
Root Password: VMware1!
SSH Enabled: check/uncheck
Directory Domain Name: vghetto.local
New Identity Domain: check
Directory Password: VMware1!
Site Name: virtuallyGhetto

For a vCenter Server Management Node only , you will need to edit the following (below is an example of the data input):

Host Network IP Address: 192.168.110.100
Host Network IP Address Family: ipv4
Host Network DNS Servers: 192.168.110.10
Host Network Default Gateway: 192.168.110.1
Host Network Mode: static
Host Network Identity: vc-01a.corp.local
Host Network Prefix: 24
Tools-based Time Synchronization Enable: check OR NTP Servers
Platform Services Controller: psc-01a.corp.local
Root Password: VMware1!
SSH Enabled: check/uncheck
Directory Domain Name: vghetto.local
New Identity Domain: uncheck
Directory Password: VMware1!
Site Name: virtuallyGhetto

For a Platform Services Controller Node only, you will need to edit the following (below is an example of the data input):

Host Network IP Address: 192.168.110.110
Host Network IP Address Family: ipv4
Host Network DNS Servers: 192.168.110.10
Host Network Default Gateway: 192.168.110.1
Host Network Mode: static
Host Network Identity: psc-01a.corp.local
Host Network Prefix: 24
Tools-based Time Synchronization Enable: check OR NTP Servers
Root Password: VMware1!
SSH Enabled: check/uncheck
Directory Domain Name: vghetto.local
New Identity Domain: check
Directory Password: VMware1!
Site Name: virtuallyGhetto

If everything was deployed successfully, you should now have a VCSA 6.0 instance running in either your vCloud Director or vCloud Air environment.

Share this...
  • Twitter
  • Facebook
  • Linkedin
  • Reddit
  • Pinterest

Filed Under: Automation, OVFTool, vCloud Air, VCSA, vSphere 6.0 Tagged With: ova, ovf, ovftool, vcd, vcloud air, vcloud director, vcsa, vcva, vSphere 6.0

CoreOS is now available as OVA in Alpha channel

01/08/2015 by William Lam 11 Comments

It looks like the folks over at CoreOS have now also produced an OVA image which can be easily imported into a vSphere or even vCloud Air environment. Previously, it took a few addition steps to convert the "hosted" disk image originally meant for VMware Fusion/Workstation to properly work in a vSphere/vCloud Air based environment. The CoreOS OVA is currently only available in the CoreOS Alpha channel for the "Production" image which also includes VMware's open-vm-tools and the latest release as of today is CoreOS 554.0.0.

You can using either the vSphere C# or vSphere Web Client to import the OVA or you can automate this simply by using command-line via ovftool. Here's an example snippet that you can run directly against an ESXi host:

Shell
1
2
3
4
5
6
7
/Applications/VMware\ OVF\ Tool/ovftool \
        --name=CoreOS \
        "--net:VM Network=VM Network" \
        --datastore=mini-local-datastore-2 \
        --diskMode=thin \
        'http://alpha.release.core-os.net/amd64-usr/554.0.0/coreos_production_vmware_ova.ova' \
        'vi://root:*protected email*'

You can also import the CoreOS OVA into vCloud Air's but you will need to connect into the vCloud Director interface to upload or you can also use ovftool. For more details on how to import using ovftool, check out their documentation here.

Here's a screenshot of deploying CoreOS from a vCloud Air Catalog:

Screen Shot 2015-01-08 at 8.39.48 AM
The "Production" CoreOS image does not contain insecure SSH keys as the "insecure" image and so you will still need to create a Cloud Config ISO if you wish to further customize the image including login credentials. You can take a look at the script I had created for deploying CoreOS from the Stable channel and for more details check out the Cloud Config documentation as well.

Share this...
  • Twitter
  • Facebook
  • Linkedin
  • Reddit
  • Pinterest

Filed Under: Docker, ESXi, Fusion, vSphere, Workstation Tagged With: coreos, esxi, fusion, ova, ovftool, vcloud air, vcloud director, workstation

Configuring a “Whitelist” for VM advanced settings in vCloud Director

05/10/2014 by William Lam 3 Comments

The ability to preserve a Virtual Machine's "virtual hardware personality" during an export has been around since the release of vSphere and vCloud Director 5.1 also known as a Lossless OVF Export. However, when it comes time to import that Virtual Machine back into your environment, will it be a "lossless" import? For vSphere, the answer is yes as long as you click on the "Accept extra configuration options" during the import of your OVF/OVA in the vSphere Web Client.

whitelist-vmx-settings-vcloud-director
For vCloud Director however, the answer is sadly no. If you try to import an OVF/OVA that contains additional VM advanced settings, vCloud Director will automatically strip away these parameters before importing the Virtual Machine. As annoying as this is for end users, there is a very good reason why this happens.

In a public cloud you do not know who your users are and whether they have malicious intentions. Since the "Extra Configuration" of a Virtual Machine can not be validated, the safest way to guard against this type of a security risk is by sanitizing the content prior to upload.

Although I have known about this default behavior in vCloud Director for some time now, it was only in a recent meeting with some of our internal folks managing our OneCloud environment did I realize how annoying this behavior was for "private" clouds as well. I was looking to import an existing OVF that contains several VM Advanced settings, but realized this would not be supported due to the sanitization of the OVF.

The other issue is that vApps within OneCloud are also exported/re-imported into other vCloud Director environments. Even if our Cloud Administrator were to make a one time exception and manually add these these VM Advanced Settings, they would automatically be stripped away the next time they were re-imported into another environment. After our meeting, I thought there had to be a better way! (at least I hope)

Disclaimer: This may or may not be officially supported by VMware, please use at your own risk.

In doing a quick bit of research, it turns out this is actually a pretty elegant solution that allows you to create a "Whitelist" of trusted VM advanced settings that would be accepted as part of the import process in vCloud Director. To configure this "Whitelist", you will need to add a new category called ExtraConfigWhitelist into the vCloud Director Database for each and every VM advanced setting that you wish to allow.

To demonstrate this functionality, I have the latest vCloud Director appliance (I believe this should also work on 5.1 as well) running and I would like to add the following VM advanced settings to the whitelist:

  • scsi0:0.virtualSSD
  • scsi0:1.virtualSSD
  • scsi0:2.virtualSSD
  • disk.enableUUID

Before starting, you will need to SSH to our vCloud Director instance and stop the VCD service by running the following command:

/etc/init.d/vmware-vcloud stop

Next, you will need to switch over to the "oracle" user by running the following command:

su - oracle

Login to the VCD Database. For the VCD appliance I am using sqplus and the default username/password:

sqlplus vcloud/VCloud

Once you have logged in, you will need to insert the following rows into the "config" table of VCD Database:

INSERT INTO config (config_id, cat, name, value, sortorder) VALUES (seq_config.NextVal, 'ExtraConfigWhitelist', 'scsi0:0.virtualSSD', 'true', 0);
INSERT INTO config (config_id, cat, name, value, sortorder) VALUES (seq_config.NextVal, 'ExtraConfigWhitelist', 'scsi0:1.virtualSSD', 'true', 0);
INSERT INTO config (config_id, cat, name, value, sortorder) VALUES (seq_config.NextVal, 'ExtraConfigWhitelist', 'scsi0:2.virtualSSD', 'true', 0);
INSERT INTO config (config_id, cat, name, value, sortorder) VALUES (seq_config.NextVal, 'ExtraConfigWhitelist', 'disk.enableUUID', 'true', 0);

Note: The syntax used here is for an Oracle database. You may need to tweak it if you are using MS SQL Server.

Finally, for the changes to go live you just need to start up your VCD instance:

/etc/init.d/vmware-vcloud start

Once the VCD service has returned, you can now import any OVF/OVA that contains a list of approved VM advanced settings and VCD will ensure these settings are preserved as part of the import. I hope this solution is something our OneCloud team will consider as it solves my immediate problem but I also think this can greatly benefit the overall use base, especially those building out content.

Note: Even though this "whitelist" option is available, I would still recommend you carefully determine which VM advanced setting is required for your environment and minimize the size of the list as much as possible from an operational perspective, especially when it comes to new installation or upgrades.

Share this...
  • Twitter
  • Facebook
  • Linkedin
  • Reddit
  • Pinterest

Filed Under: Not Supported Tagged With: import, lossless, ova, ovf, security, vcd, vcloud director, vmx

How To Run The SilverLining Fling Without Installing It In vCloud Director

02/26/2013 by William Lam 5 Comments

A few weeks back the VMware Lab's team released a cool new fling called SilverLining which allows users to build a simplified user-interface for vCloud Director. This interface can be run from any modern web-browser that supports HTML5, CSS3 and Javascript. To access the SilverLining interface, you must first install it on a vCloud Director 5.1 Cell.

From a development or proof of concept perspective, it would be really nice to be able to run SilverLining locally from your desktop and point it to a valid vCloud Director 5.1 instance for testing. Well, this is exactly what Andrea Siviero, a Consulting Architect for VMware discovered while playing around with the SilverLining Fling.

UPDATE: 2/28 - For Safari, you can use open /Applications/Safari.app/ --args -disable-web-security

Disclaimer: The solution described here is specifically for Chrome running on Mac OS X or Windows. I have not looked into equivalent settings for other browsers.

Here are the steps required to make this work:

Step 1 - Download SilverLining and extract the contents to your local desktop

Step 2 - Under Silverlining->js directory, there is a file called main.js that needs to be modified. Add the following right under "$(document).ready(function() {" which should point to the base URL of your vCloud Director instance:

localStorage.server = "https://vcd.primp-industries.com";

Step 3 - Launch Chrome with the additional argument via the command-line and load the index.html in the SilverLining directory:

open /Applications/Google\ Chrome.app/ --args -disable-web-security

Note: For Windows version of Chrome just pass in the following either via command-line or shortcut to Chrome.exe -disable-web-security

If everything was successful, you should be able to login to the vCloud Organization of your choice and see all the vApps and Catalogs you have access to!

If you receive the "You are attempting to connect to a system no longer supported" shown in the screenshot below:

You may be pointing to a vCloud Director instance that is using a self-signed certificate and you will need to trust the site before proceeding. To do so, open up a new tab and enter the following URL (substituting your vCloud Director URL):

https://vcd.primip-industries.com/api/versions

Click on the "Proceed Anyway" and then reload the index.html page and you should now be able to login to vCloud Director.

I would like to thank Andrea for sharing this awesome tip! Now you can easily develop and test your own custom interface using the Javascript SDK provided by SilverLining all on your desktop. Best of all, you can now point this to any remote vCloud Director 5.1 instance whether that be private or public!

Share this...
  • Twitter
  • Facebook
  • Linkedin
  • Reddit
  • Pinterest

Filed Under: Uncategorized Tagged With: fling, HTML5, javascript, sdk, silverlining, vcd, vcloud director, vcloud director 5.1

  • Go to page 1
  • Go to page 2
  • Go to page 3
  • Go to page 4
  • Go to Next Page »

Primary Sidebar

Author

William Lam is a Senior Staff Solution Architect working in the VMware Cloud team within the Cloud Services Business Unit (CSBU) at VMware. He focuses on Automation, Integration and Operation for the VMware Cloud Software Defined Datacenters (SDDC)

  • Email
  • GitHub
  • LinkedIn
  • RSS
  • Twitter
  • Vimeo

Sponsors

Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here: Cookie Policy