Search Results for: ovftool

Horizon View in a box using new Horizon View Config Tool

03.07.2014 by William Lam // 1 Comment

The folks over at VMware Labs have really been on fire lately. Last week, they help release another exciting new Fling called Horizon View Configuration Tool. This latest Fling, also known as VCT was developed by Marilyn Basanta, who works over in our EUC organization. Marilyn's goal for this first release of VCT was simple, to enable customers to easily and quickly deploy a basic Horizon View 5.3 environment from scratch. I had the chance to meet up with Marilyn this week in person to discuss some of my feedback regarding VCT and something that really stood out to me was that she really understood the importance of Automation. If you compare this to the manual approach today, which has many moving parts not to mention the learning curve for new VMware customers , you can see why a solution like VCT would be a valuable tool for our customers.

After VCT was announced, I knew I had to give this a spin in my home lab! After quickly glancing at the documentation, I deployed VCT and found a couple of interesting tidbits that you should be aware of before getting started.

In addition to deploying VCT, you will need to also deploy the VMware Studio virtual appliance which is used to provision Windows OSes
A standalone ESXi host that is not managed by vCenter Server
All virtual machines provisioned by VCT are "Zeroed Thick" and not Thin (minus VCT/Studio as you can specify)
At least 19GB of memory is required, not including desktops you would provision

I went through a "full" VCT deployment in my home lab which I also included an Active Directory instance and here are the resource requirements for each Virtual Machine which I know some folks were interested in:

VM	vCPU	vMEM	vDISK	DISK TYPE
View Config Tool	1	512 MB	14 GB	THIN
VMware Studio	1	512 MB	50 GB	THIN
Active Directory	2	2 GB	16 GB	ZEROED THICK
VCSA	2	8 GB	125 GB	ZEROED THICK
Horizon View	2	4 GB	20 GB	ZEROED THICK
Horizon Composer	2	4 GB	20 GB	ZEROED THICK

For a first release where a user can just provide a Windows Server 2008 ISO and specify a couple of parameters and just sit back and watch this entire environment provision automatically is very impressive. However, I thought what would be even cooler is if we can further reduce the barrier for customers to try out this awesome tool. I did a bit of digging around in the VCT appliance and found that there are a couple of "tweaks" err "hacks" that you could perform to help reduce the footprint of your Horizon View setup.

Disclaimer: These optimizations is something that I spoke to Marilyn about and among other things and she is well aware of some of these early limitations which hopefully will be addressed in future releases of VCT.

For optimization #1 and #2, you will need to perform this before you start the VCT wizard. For optimization #3, this can be done after your Horizon View environment is up and running

Optimization # 1 - Enable "Thin" provisioning of VCSA

SSH to your VCT appliance and edit the following file /apache-tomcat-7.0.27/webapps/vct/WEB-INF/classes/deploy_vCenter.py and ensure it looks like the below (changes highlighted in blue):

deploy_vm = ["/ovftool/ovftool", "-n=" + name, "-ds=" + datastore, "-dm=thin", "-nw=" + network, "--acceptAllEulas", "--noSSLVerify", vcenter_path, "vi://" + esx_username + ":" + esx_password + "@" + esx_host ]

Optimization # 2 - Enable "Thin" provisioning for Windows VMs (View, Composer & AD)

SSH to your VCT appliance and edit the following file /apache-tomcat-7.0.27/webapps/vct/WEB-INF/classes/deploy_ova_studio.py and ensure it looks like the below (changes highlighted in blue):

ssh_command = "sh /opt/vmware/share/ovftool/ovftool --name=\"" + name + "\" --datastore=\"" + datastore + "\" -dm=thin --network=\"" + network + "\" " + path + " vi://" + esx_username + ":" + esx_password + "@" + esx_host

Optimization # 3 - Reduce VCSA memory

For a small environments or POCs, you can run VCSA with 4GB of memory. The default from VMware is 8GB, but this is not the minimal and will depend on the size of your environment (# of VMs/Hosts).

With these simple modifications, you can significantly reduce the amount of storage required and more importantly reduce the amount of memory down to ~14GB if not more due to other memory saving techniques such as VMware TPS. If you already have an existing Active Directory server, you can even further reduce it. The primary reason I was interested in reducing the resource requirements (which I am always a fan of) is that I wanted to demonstrate that you could easily get a fully working Horizon View environment running on top of an Apple Mac Mini! How cool is that!? I mean anyone can be walking around with a Mac Mini that includes everything to run or demo a full Horizon View 5.3 environment. The deployment in my environment took about ~3hrs, I suspect it was slow due to my spinning rust and it should be much faster on an SSD. I was also able to get away with just needing 91.8 GB of storage (all powered on) for the base infrastructure, of course you should allocate a bit more if you want to actually deploy additional desktops.

I highly recommend those of you who are interested in Horizon View to give VCT a try and if you have any feedback or features you would like to see, please leave a comment on the Flings webpage. I know Marilyn is very interested in hearing customer feedback and how she and her team can better improve VCT in the future. Great job again Marilyn, very cool solution and glad to see there is no shortage of innovation at VMware!

Did you know OVF supports a cool feature called Dynamic Disks?

12.02.2013 by William Lam // 7 Comments

A couple of weeks back I had the pleasure of meeting Anders Madsen who is the lead engineer for the very popular and useful tool called ovftool. While having a discussion on a variety of topics with Anders I came to learn about a cool little feature of the OVF specification call Dynamic Disks. This lesser-known feature has actually been around since OVF 1.1 but I suspect that most people have probably not heard of this capability unless you are intimately familiar with the OVF format which I I know I am not.

When you deploy an OVF you are pretty much deploying a static pre-configured Virtual Appliance that contains a certain amount of cpu, memory and storage. One can easily increase the CPU/Memory of the appliance after provisioning or leverage OVF's Flexible Deployment Options during the deployment of an OVF. On the Storage front it is a bit more difficult since the maximum capacity of each virtual disk is already pre-defined. Similar to CPU/Memory, once the OVF has been deployed you can easily extend the virtual disk(s) but you must also ensure you extend it in the guestOS either manually or automatically using built-in intelligence from the application.

What would be really nice is to have the ability to specify the capacity of a given set of virtual disks during deployment run-time instead of relying on a fixed capacity which is what Dynamic Disks allows you to do. This capability is only applicable for empty virtual disks and does not apply to virtual disks that already contain data such as an operating system or data disk. A great use case for such a feature could be an NFS Server Virtual Appliance where you would have an OS installed on the first virtual disk and then a couple other virtual disks that would be used for the underlying NFS Server volumes. Instead of having a fixed size for the NFS Server Virtual Appliance, it can be dynamically configured during deployment and it is up to the application to have the appropriate logic to handle the setup of the virtual disks during first bootup.

Here is an example of what this would like when deploying an OVF using Dynamic Disks:

You can see from the above screenshot, the OVF I am deploying contains two Dynamic Disks which have a default value of 5GB and 10GB. However, during the deployment I can change these default values to something different.

Instead of of 5GB and 10GB, I decided to change it to 10GB and 15GB and these values will be reflected by the platform that will be used to deploy the OVF whether that is vSphere, Fusion or Workstation. Another great use case for Dynamic Disks is to update the OVF I built to quickly help setup and test VMware VSAN (Virtual SAN) using Nested ESXi. The OVF that I created contains three empty virtual disks: 2GB for ESXi installation, 4GB for virtual SSD and 8GB for mechanical disk. Instead of requiring a user to reconfigure the virtual disks after deployment, you can now specify the capacity you want for each of the virtual disks using the new OVF that I have created here.

I hope to see more Virtual Appliances take advantage of Dynamic Disks capability as it can be useful for providing customized deployment options while still maintaining the notion of a pre-configured system. If you wish to create your own OVF that utilizes Dynamic Disks, please take a look at the instructions below.

Step 1 - Create a Virtual Machine like you normally would that contains both empty and non-empty virtual disks. In the example I have created a VM in vSphere which contains one virtual disk which would contain an OS (in this example its just empty) and two additional virtual disks (disk 2 and 3) which will be used for Dynamic Disks.

Step 2 - Export the VM to an OVF and delete the virtual disks files that will be used as Dynamic Disks as well as the OVF Manifest file as the contents will change.

Step 3 - Next we will need to make a couple of edits to the OVF descriptor file and the first change is to delete the virtual disks reference entries that will be used for Dynamic Disks. In this example that will be disk2 and disk3 as seen in the screenshot below.

Step 4 - We now need to delete the fileRef property for our two virtual disks located in DiskSection which is usually located at the top of the file. We also need to modify the capacity values into variables that will be used within the OVF file. You can select any name you want for the variable and in this example I chose ${disk1size} and ${disk2size}.

Step 5 - Finally, you need to add two new property entries which is embedded in the ProductionSection of the OVF descriptor and usually located towards the bottom of the file. Also make sure this sits under the VirtualHardwareSection but before the VirtualSystem tag as seen in the screenshot below.

    <ProductSection>
      <Info>Information about the installed software</Info>
      <Product>NFS Server</Product>
      <Vendor>virtuallyGhetto</Vendor>
      <Version>1.0</Version>
      <Property ovf:key="disk1size"
            ovf:runtimeConfigurable="false"    
            ovf:type="int"
            ovf:qualifiers="MinValue(1) MaxValue(10000)"
            ovf:value="5"
            ovf:userConfigurable="true">
        <Label>NFS Datastore Size for Disk 1</Label>
        <Description>The size of the disk in gigabytes.</Description>
      </Property>
      <Property ovf:key="disk2size"
            ovf:runtimeConfigurable="false"
            ovf:type="int"
            ovf:qualifiers="MinValue(1) MaxValue(10000)"
            ovf:value="10"
            ovf:userConfigurable="true">
        <Label>NFS Datastore Size for Disk 2</Label>
        <Description>The size of the disk in gigabytes.</Description>
      </Property>
    </ProductSection>

The two disk variables that we defined earlier is used in this section that allows you to specify a default value as well as some additional text that can be displayed for each property. Instead of having you copy/paste from the blog I have provided a sample OVF that consumes Dynamic Disks in which you can use as an example for creating your own. To use this OVF you will need to download the following two files and then import into your environment:

Dynamic-NFS-Server.ovf
Dynamic-NFS-Server-disk1.vmdk

Once you have made all the necessary changes, you can then deploy the new OVF and the OVF wizard should now detect that Dynamic Disks are being used and you should see a message similar to the one below.

How to bootstrap vCenter Server onto a single VSAN node Part 2?

09.09.2013 by William Lam // 47 Comments

In this article, I will provide a step by step walk through on how to setup and configure single VSAN node that will allow you to deploy a vCenter Server onto a VSAN datastore. This initial "bootstrapping" can help when initially building out your VSAN cluster and can come in handy for greenfield deployments and potentially for brownfield deployments as well. Before getting started, make sure you have taken a look at How to bootstrap vCenter Server onto a single VSAN node Part 1.

Environment:

3 physical host
Each host as a small iSCSI boot LUN for ESXi installation (this can be another local disk or USB/SD card)
Each host has single SSD and SATA disk (minimum)

Step 1 - Install ESXi 5.5 onto your physical hosts, we technically only need one host to begin the process but you will probably want to have two additional hosts ready unless you do not care about your vCenter Server being able to recover if there is any hardware issues.

Step 2 - You will need to modify the default VSAN storage policy on the ESXi host in which you plan to provision your vCenter Server. It looks like this behavior changed during the VSAN beta and when VSAN was GA'ed yesterday with vSphere 5.5 Update 1. You will need to run the following two ESXCLI commands to enable "force provisioning":

esxcli vsan policy setdefault -c vdisk -p "((\"hostFailuresToTolerate\" i1) (\"forceProvisioning\" i1))"
esxcli vsan policy setdefault -c vmnamespace -p "((\"hostFailuresToTolerate\" i1) (\"forceProvisioning\" i1))"

You can confirm you have the correct VSAN default policy by running the following ESXCLI command:

~ # esxcli vsan policy getdefault
Policy Class Policy Value
------------ --------------------------------------------------------
cluster       (("hostFailuresToTolerate" i1))
vdisk         (("hostFailuresToTolerate" i1) ("forceProvisioning" i1))
vmnamespace   (("hostFailuresToTolerate" i1) ("forceProvisioning" i1))
vmswap        (("hostFailuresToTolerate" i1) ("forceProvisioning" i1))

We start off with our first ESXi host and as you can see from the screenshot below, we do not have additional datastores that we can use to provision our vCenter Server.

Step 3 - You will need to identify the disks that you will be using on the first ESXi host to contribute to the VSAN datastore. You can do so by running the following ESXCLI command:

esxcli storage core device list

To get specific details on a particular device such as identifying whether it is an SSD or regular HDD, you can specify the -d option and the device name.

Once you have identified the disks you will be using, make a note of the the disks names as they will be needed in the upcoming steps. As mentioned in my environment, I only have a single SSD and single HDD and their respective device names are naa.50026b72270126ff & naa.5000c500331bca77

Step 4 - Before we can create our VSAN datastore, we need to first create a VSAN cluster. One of the parameters that is needed when going through this "bootstrapping" method without a vCenter Server is a unique UUID to identify the VSAN cluster. The UUID is in the format of "nnnnnnnn-nnnn-nnnn-nnnn-nnnnnnnnnnnn" where n is a hexidecimal value. You can easily generate one within the ESXi Shell by leveraging the following Python snippet

python -c 'import uuid; print(str(uuid.uuid4()));'

Step 5 - To create a VSAN cluster, we will use the following ESXCLI command and specify the UUID from the previous step for the -u option:

esxcli vsan cluster join -u UUID

UPDATE (02/11/15) - In vSphere 6, you no longer have to perform step 4 to generate a UUID. There is now a new ESXCLI command which will automatically create a VSAN Cluster and generate a UUID automatically by running the following command:

esxcli vsan cluster new

Once the VSAN cluster has been created, you can retrieve information about the VSAN cluster by running the following ESXCLI command:

esxcli vsan cluster get

Step 6 - Next we need to add the disks from our ESXi host to create our single node VSAN datsatore. To do so, we will need the disk device names from our earlier step for both SSD and HDDs and run the following ESXCLI command:

esxcli vsan storage add -s SSD-DISK-ID -d HDD-DISK-ID

The -d option specifies regular HDD disks and the -s option specifies an SSD disk. If you have more than one HDD disk, you will need to specify multiple -d entries. You can also take a look at the disks being contributed to the VSAN datatore by running the following ESXCLI command:

esxcli vsan storage list

Step 7 - To save us one additional step, you can also enable the VSAN traffic type on the first ESXi host using ESXCLI and you can also do this for the other two hosts in advance. This step does not necessary have to be done now as it can be done later when the vCenter Server is available and using the vSphere Web Client. You will need to either create or select an existing VMkernel interface to enable the VSAN traffic type and you can do so by running the following ESXCLI command:

esxcli vsan network ipv4 add -i VMK-INT

At this point, you now have a valid VSAN datastore for your single ESXi host! You can verify this by logging into the vSphere C# Client and you should see the VSAN datastore mounted to your ESXi host.

At this point, you are now ready to deploy your vCenter Server 5.5 onto the VSAN datastore. The next series of steps outline the deployment of the VCSA for completeness of the article.

Step 8 - Deploy the VCSA 5.5 OVA/OVF onto the VSAN datastore and power on the VM.

UPDATE: You skip Steps 9-11 by leveraging ovftool 4.0 to inject the required OVF properties when deploying the VCSA, take a look at this article for more details.

Step 9 - Since you can not configure the OVF properties for the VCSA, you will notice that networking is not configured (unless you happen to have DHCP on the network). If you are like most Enterprise customers, you will not have DHCP running in your environment and you will need to configure a static IP.

Step 10 - Login to the VCSA console and we will use the following VAMI CLI /opt/vmware/share/vami/vami_set_network to configure the IP Address for the VCSA. Here is an example of what that command would look like:

/opt/vmware/share/vami/vami_set_network eth0 STATICV4 172.24.68.14 255.255.255.0 172.24.68.1

For more details on the syntax, you can refer to this blog article here. At this point, you should be able to ping your VCSA and verify connectivity.

Step 11 (Optional) - In addition to IP connectivity, you may also want to configure your DNS Server and DNS search domain before configure the VCSA application. You can also do this by using the following VAMI CLI /opt/vmware/share/vami/vami_set_dns and for search domain, you would need to add the entry to /etc/resolve.conf

Step 12 - You now are ready to configure the VCSA. Open a browser and connect to https://[VCSA-IP]:5480 and proceed through the VCSA setup wizard.

Step 13 - Once the VCSA has been configured, you can now login to the vSphere Web Client and create a Datacenter object and then a vSphere Cluster and enable VSAN. Make sure you also enter your VSAN beta license key under the "Manage" section of the vSphere Cluster before you can use VSAN.

Step 14 - Add all three of your ESXi hosts to the vSphere Cluster. If you recall earlier we had enabled the VSAN traffic type on our first ESXi host and if you did not run the command on the remainder ESXi hosts, you will need to do so using the vSphere Web Client under the "Networking" section of each ESXi host

Step 15 - Once all three ESXi hosts have been added to the vSphere Cluster, we should now see their local storage contributed to the VSAN datastore under the "General" tab

Step 16 (Optional) - If for whatever reason the disks do not get automatically claimed, you can click on "Disk Management" and manually claim them. If you selected "Automatic" mode when enabling VSAN, the disks on each ESXi host should automatically be handled by VSAN. However, they may not be claimed if the disks are being seen as "remote" versus "local" devices.

Step 17 - The final thing I would recommend is to configure the VCSA to automatically startup and shutdown when the ESXi host reboots. To do so, login to the ESXi host using the vSphere C# Client and click on "Virtual Machine Startup/Shutdown" under the Configuration tab.

So there you have it! You are now running the vCenter Server on top of the VSAN datastore without having to initially setup a local VMFS or rely on an external NFS volume to deploy your vCenter Server and build up to the full VSAN cluster. By leveraging this bootstrap method, you can easily standup a fully self contained storage and compute cluster which is ideal for an SMB or ROBO environment. The best part of about this setup is that the VCSA will use the default VSAN storage policy which is to tolerate at least one failure and as you add your 2nd and 3rd ESXi host, you will automatically have resiliency for the VCSA.