WilliamLam.com

  • About
    • About
    • Privacy
  • VMware Cloud Foundation
    • VMware Cloud Foundation 9
  • VKS
  • Homelab
    • Hardware Options
    • Hardware Reviews
    • Lab Deployment Scripts
    • Nested Virtualization
    • Homelab Podcasts
  • VMware Nostalgia
  • Apple

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.

Categories // Not Supported Tags // import, lossless, ova, ovf, security, vcd, vcloud director, vmx

Deploy a truly dynamic OVF using Deployment Option based on the 4 Computes (CPU, Memory, Storage & Network)

12.04.2013 by William Lam // 4 Comments

After learning about the Dynamic Disks feature in OVF, I decided to revisit OVF Deployment Options again and investigate whether it was possible to include all four computes (CPU, Memory, Storage and Network) as part of the deployment option. What would be really nice is to have a flexible deployment option which allows a user to select a specific "size" or "configuration" based on their environment and the appropriate recommended compute (CPU, Memory, Storage and Network) will automatically be selected as part of the Virtual Appliance deployment.

Below is an example of what the three "Sizes" (Small, Medium and Big) could look like:

We could have easily changed "Size" to "Deployment Type" (Dev, Test, Prod) or any other definition for that matter since as this is just a string text and configuration mapping. To demonstrate the above configuration using OVF Deployment Options I have created a sample OVF called Dynamic-vGhetto-vApp.ovf that can be downloaded here.

To use the Dynamic-vGhetto-vApp.ovf example OVF, you will need to have access to a vCenter Server since the OVF Deployment Options feature is only available there. As part of the OVF deployment wizard, you should now see a new section for Deployment Options providing a drop down menu for a Small, Medium or Large deployment and can include a description for each configuration as seen in the screenshot below.

For the CPU/Memory section it is pretty straight forward on how it works and you can get more details by taking a look at this blog article here. For the Storage section we are leveraging the recetnly discovered feature of Dynamic Disks and you can refer to this article here for further details. The last compute that we have not taken a look at before is the Network section which will allows a user to assign a certain number of virtual network adapters based on the selected deployment option.

There are two parts to the Networking section, the first is the OVF network labels which are defined in the NetworkSection of the OVF descriptor as seen in the example below:

    <Network ovf:name="ManagementNetwork1">
      <Description>Management Network 1</Description>
    </Network>
    <Network ovf:name="DataNetwork">
      <Description>Data Network</Description>
    </Network>
    <Network ovf:name="ReplicationNetwork">
      <Description>Replication Network</Description>
    </Network>
    <Network ovf:name="ManagementNetwork2">
      <Description>Management Network 2</Description>
    </Network>

Each OVF network label is defined using the ovf:name property and that is then mapped to the appropriate virtual network adapter Item. To control the number of virtual network adapters for each deployment option, you will use the ovf:configuration property and specify the deployment type that are applicable for each virtual network adapter.

      <Item ovf:configuration="small medium large">
        <rasd:AddressOnParent>7</rasd:AddressOnParent>
        <rasd:AutomaticAllocation>true</rasd:AutomaticAllocation>
        <rasd:Connection>ManagementNetwork1</rasd:Connection>
        <rasd:Description>VmxNet3 ethernet adapter on "Management Network 1"</rasd:Description>
        <rasd:ElementName>Network adapter 1</rasd:ElementName>
        <rasd:InstanceID>12</rasd:InstanceID>
        <rasd:ResourceSubType>VmxNet3</rasd:ResourceSubType>
        <rasd:ResourceType>10</rasd:ResourceType>
        <vmw:Config ovf:required="false" vmw:key="wakeOnLanEnabled" vmw:value="true"/>
      </Item>

You can refer to Dynamic-vGhetto-vApp.ovf for a complete working example of the Networking section.

One thing to note for the Networking section when selecting your Deployment Option is that ALL virtual network adapters will be shown in the UI, but you only need to specify the destination portgroup mapping for the OVF labels that will be provisioned for your particular configuration. I know this can be a little bit confusing but you can ignore the others. To give you a concrete example, the "Small" configuration only deploys the VM with a single virtual network adapter which maps to the "ManagementNetwork1" OVF label and this is the only destination portgroup mapping you need to specify, you can ignore the rest.

Here is a screenshot of the Virtual Machine configurations using a "Small" deployment:

Here is a screenshot of the Virtual Machine configurations using a "Medium" deployment:

Here is a screenshot of the Virtual Machine configurations using a "Large" deployment:

I think this is probably by far the coolest feature of OVF and I really hope to see more Virtual Appliances leverage this feature including appliances built from VMware. I would like to give a big thanks to Anders Madsen for helping me put the final two pieces of the puzzle together for Deployment Options leveraging all four computes.

Categories // Uncategorized Tags // deployment options, DeploymentOptionSection, dynamic disks, ova, ovf

Exporting An Amazon EC2 Instance To Run On vSphere

05.02.2013 by William Lam // 15 Comments

I attended the Silicon Valley VMUG yesterday and there was an interesting question that was brought up at the end of Joe Sarabia's Software Defined Datacenter session (which was great BTW, folks stayed past the end and this was during lunch!). The question from the attendee was how to export an Amazon EC2 Instance and run that on an vSphere ESXi host? Joe's answer was that there is not a tool from VMware but there should be some 3rd party tools out there that could help with this task.

This was not something I had really thought about before since I do not use Amazon EC2 and of course that perked my curiosity. I assumed importing and exporting Instances to and from Amazon EC2 would be just as easy as it is on VMware vSphere. To export a VM in vSphere, you simply select the VM and then Export which can be outputted to either an OVF or OVA format.

After a quick search on Amazon's EC2 website, I found that you can export an EC2 Instance by using EC2 API Tools. So I went ahead and deployed both a Linux and Windows Instance and ran through the installation of the EC2 API Tools on my Mac OS X system at home. I tried to export the Linux Instance and it threw an error saying not supported which I thought was odd and then tried the Windows Instance and it threw another interesting error:

Client.NotExportable: Only imported instances can be exported.

My initial thought was that I must have done something wrong. I dug a bit more into Amazon's documentation which was not very easy to find and finally found the Exporting EC2 Instance documentation. It turns out there are a few "caveats" if you want to export an EC2 Instance:

Only the following operating systems are supported:

  • Windows Server 2003 R2 (Standard, Enterprise, and Datacenter)
  • Windows Server 2008 (Standard, Enterprise, and Datacenter)
  • Windows Server 2008 R2 (Standard, Enterprise, and Datacenter)

This meant that you could not export any of your Linux Instances. In addition, these Instances must be uploaded by the user initially for them to be eligible for export. I also found there were several other export limitations:

  • You cannot export Amazon Elastic Block Store (Amazon EBS) data volumes.
  • You cannot export an instance that has more than one virtual disk.
  • You cannot export an instance that has more than one network interface.

I was actually quite surprised to see how difficult and restrictive Amazon has made it for exporting their EC2 Instances, I really thought it would have been just as easy as it is on VMware vSphere. I also came across this VMware KB 1018015 which provides an alternative to the EC2 API Tools, which has you install VMware Converter on the Windows system to export the EC2 Instance.

Categories // Uncategorized Tags // amazon ec2, export, ova, ovf, vSphere

  • « Previous Page
  • 1
  • …
  • 8
  • 9
  • 10
  • 11
  • Next Page »

Search

Thank Author

Author

William is Distinguished Platform Engineering Architect in the VMware Cloud Foundation (VCF) Division at Broadcom. His primary focus is helping customers and partners build, run and operate a modern Private Cloud using the VMware Cloud Foundation (VCF) platform.

Connect

  • Bluesky
  • Email
  • GitHub
  • LinkedIn
  • Mastodon
  • Reddit
  • RSS
  • Twitter
  • Vimeo

Recent

  • Capturing Kasa Smart Plug Power Metrics using VCF Operations Management Pack Builder 11/07/2025
  • Retrieving the vSAN Cluster Shutdown VMs running Pre-Check Results using PowerCLI 11/05/2025
  • JFrog Artifactory as VCF Software Depot for VCF Installer & SDDC Manager 11/03/2025
  • Identifying VMware Cloud Foundation (VCF) managed service accounts in vCenter Server 10/30/2025
  • Configuring VCF Automation (VCFA) Organization Portal OIDC IdP using Terraform Provider for VCFA 10/28/2025

Advertisment

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

Copyright WilliamLam.com © 2025

 

Loading Comments...