OVF files created as vApps cannot be deployed directly to vSphere hosts, they must be deployed via vCenter.
Invalid arguments – related to vapprun being a batch file. Variables and arguments need to be placed in quotes.
Not Found – Arguments are case-sensitive ( Linux compatibility)
To date – VMware vCloud director is currently not compatible with OVF vApps. They must be exported to vCenter, then converted to vCloud format.
VAPP.cmd:
—
@ ECHO OFF
rem # VAPPRUN TESTING SCRIPT
rem # — Set Variables –
set VAPP=TESTAVAPP
set VM1=TESTAVM1
set VM2=TESTAVM2
rem # Set Disk size in GB
set DISK=5
rem # — END Set Variables –
rem # — Start Creation –
rem # Create vAPP Container
echo Initializing vAPP Container called %VAPP%
call vapprun init
rem # Create or Link VM with VMDK Disk
echo Creating %VM1%
call vapprun create-vm %VM1% “disk=%DISK%”
rem # Create or Link VM with VMDK Disk
echo Creating %VM2%
call vapprun create-vm %VM2% “disk=%DISK%”
rem # Create vAPP Instance
echo Creating vAPP called %VAPP%
call vapprun create-vapp %VAPP%
rem # Link VM to vAPP Instance
echo Linking %VM1% to vAPP Container %VAPP%
call vapprun edit %VM1% “parent=%VAPP%”
rem # Link VM to vAPP Instance
echo Linking %VM2% to vAPP Container %VAPP%
call vapprun edit %VM2% “parent=%VAPP%”
rem # List VM / vAPP status
call vapprun list
rem # Set Startup Order
call vapprun edit %VM1% “startOrder=10″ “startWait=10″ “waitForTools=True” “stopWait=10″
rem # Set Startup Order
call vapprun edit %VM2% “startOrder=20″ “startWait=10″ “waitForTools=True” “stopWait=10″
rem # Start vAPP and VM Guests in Workstation
echo Starting Composite vAPP “%VAPP%”
call vapprun start -gui %VAPP%
rem # List VM / vAPP Status
call vapprun list
The following script illustrates how the vApprun command ‘links’ to VM’s to allow them to become part of the vApp via the path to .vmx files:
VAPPLNK.cmd:
—
@ ECHO OFF
rem # VAPPRUN TESTING SCRIPT
rem # — Set Variables –
set VAPP=TESTAVAPP
set VM1=TESTAVM1
set VM2=TESTAVM2
rem # — Linked VM Variables –
set VM1LINKPATH=”vmx=.\WindowsServer2008R2x64\WindowsServer2008R2x64.vmx”
set VM2LINKPATH=”vmx=.\WindowsServer2008R2x64.2\WindowsServer2008R2x64.vmx”
rem # — END Set Variables –
rem # — Start Creation –
rem # Create vAPP Container
echo Initializing vAPP Container called %VAPP%
call vapprun init
rem # Create or Link VM with VMDK Disk
echo Creating %VM1%
.\src\vapprun.py link-vm %VM1% %VM1LINKPATH%
rem # Create or Link VM with VMDK Disk
echo Creating %VM2%
.\src\vapprun.py link-vm %VM2% %VM2LINKPATH%
rem # Create vAPP Instance
echo Creating vAPP called %VAPP%
call vapprun create-vapp %VAPP%
rem # Link VM to vAPP Instance
echo Linking %VM1% to vAPP Container %VAPP%
call vapprun edit %VM1% “parent=%VAPP%”
rem # Link VM to vAPP Instance
echo Linking %VM2% to vAPP Container %VAPP%
call vapprun edit %VM2% “parent=%VAPP%”
rem # List VM / vAPP status
call vapprun list
rem # Set Startup Order
call vapprun edit %VM1% “startOrder=10″ “startWait=10″ “waitForTools=True” “stopWait=10″
rem # Set Startup Order
call vapprun edit %VM2% “startOrder=20″ “startWait=10″ “waitForTools=True” “stopWait=10″
rem # Start vAPP and VM Guests in Workstation
echo Starting Composite vAPP “%VAPP%”
call vapprun start -gui %VAPP%
rem # List VM / vAPP Status
call vapprun list
—-
As illustrated, vApps may be created in batch to ensure repeatability and testing.
The Open Virtualization Format (OVF) is an industry standard that contains metadata about Virtual Machine images in XML format. The OVF Tool provided by VMware (Version 2.0.1 | May 2011) converts vSphere, VMX (VM), OVA (Xensource), and vApp sources and targets including vApprun Workspaces. The OVFTool can be used to deploy via the command-line directly to vCenter including vApps created by VMware Workstation using vApprun. Sources can be invoked from http, https, ftp, and local filesystems. The OVFTool has the capability to sign and validate OVF x509 certificate signatures. OVF Support is also built into the vSphere Client and the OVFTool can also deploy directly to a vApprun Workspace.
VMware Workstation can be used to create or evaluate OS images on a client PC. Once created, they can be converted to the OVF format. Once they are converted to OVF, they can be deployed on a vCenter Server or vSphere host. Gold OS images may also have parameters that may be scripted after being unique via Sysprep; then customized via OVF environment variables that may be invoked after post installation.
From a vApp context, a Virtual Machine may be linked or created by tools such as VMware Workstation, vSphere VI Client, vCLI, PowerCLI, and vApprun. The Virtual Machine is an independent entity that is ‘linked’ within a given vApp. Once a Virtual Machine is created, it can then be converted to an OVF as an Appliance. If a requirement is in need of multiple VM’s, they can be grouped or linked into a vApp and also converted into an OVF composite file as an Application Appliance. Once VM’s and vApps are converted to OVF, they are compressed with a ratio greater than 50%, and are transportable to vSphere Hosts and vCenter Servers respectively.
For example, a vApp with 2 VM’s may have 80GB disks that are ‘thin-provisioned’. Since these disks are thin, the average usage of a Windows 2008 R2 OS would be at 8GB of disk usage. With 2 VM’s this would be 16GB with 160GB datastore ‘potential storage’. Once converted to an OVF, these VM’s consume roughly 6.5GB of space for deployment. By comparison that equates to a 96% savings in storage space for Gold Model provisioning for the OS only. Once deployed, the ‘thin’ provisioned disks may be converted to ‘thick’ to enhance performance via SVMotion or on the fly via the ‘thicktarget’ switch within the OVFTool command.
On the VMware platform, Virtual Application stacks known as vApps are created as containers that support multiple virtual machines that can be created as a composite software solution. This article series also outlines VMware Workstation and OVFTool capabilities in the creation of vApps. The vApp solution can be packaged and deployed via a single OVF (Open Virtual Format) file descriptor. A vApp has power-on order operations for multiple VM Guests and allows for a flexible mechanism of paremeters being established within each given VM guest. VMware vApp containers include Resource Pool functionality within the vAPP and OS level properties that may be configured on the fly such as IP addressing, configurations and automated scripts within a contained vApp VM Guest.
More to follow in this Series…
IPv6 can be very intimidating. Guess what, you may already have it on your network. For example try pinging ::1. Now you know… There are millions of addresses that can be created from an IPv6 Address. If you look down at a square yard of sand. You can potentially assign an IP address to each grain, and have plenty to go.
Here is what is interesting about IPv6 that we will cover in this series of articles.
1. It is easier to configure than IPv4 (crazy)
2. It is easier to configure IPv6 on Cisco Equipment (no way! Yes MPBGP is easier)
3. There is no subnetting. (What? Now I can’t impress anyone…) More on this including the breakdown of the IPv6 Address. The new fancy word is called a ‘prefix’. (Add that to your resume’. It makes a great keyword…)
4. There are no broadcasts. (That’s great, no more network related calls… I can retire.)
5. ICMP is required. It basically replaces ARP for Layer 2 to Layer 3 Discovery. It is called Neighbor Discovery (ND or NDP)…(I like my neighbors, not sure if they feel the same.)
6. Routes are auto-summarized. (The world is smaller now.)
7. Everyone gets an address, and DHCP is not required. (Still recommended though.)
8. Multiple addresses can be assigned to the same interface with the same priority (All about teamwork, no superstars allowed…Remember – You were not allowed to be Outstanding in Elementary School. Satisfactory for Everyone!)
I will dive deeper into each point…. Be sure to get your ISP to give you an IPv6 Prefix.
Once you have it, enjoy your 65,536 networks.
We are big fans of Automation. This includes automation of VMware performance and load testing. ESXTop is a great tool used with ESXPlot for performance troubleshooting. It gives the big picture from the vSphere Host point of view. The following script installed on a vSphere host will automatically create and archive log files for 65 Minutes (5 minutes for ramping up.). This can be scheduled and ran remotely via PLINK. More to Follow…
—-Script—
#!/bin/sh
#
# ESXTOP Log File Creation and Automation Script
#
# VirtualOSiti LLC 2011
#
# Command: esxtop -a[All] -b[Batch] -d[Delay in Seconds] -n[Interations]
# Note: Do not export variables
#TIME CREATED
TIMESTAMP=$(date “+%b-%d-%y-%H-%M-%S”)
#LOGFILE NAME
LOGFILE=”esxtop-capture-”$TIMESTAMP”.csv”
#LOGFILE PATH
LPATH=/
#OPTIONAL CONFIG FILE
CONFIG=/ESXTOP_PERF_CONFIGURATION
#DELAY (Seconds)
DELAY=5
#ITERATIONS
ITERATIONS=840
#COMMANDS
#This will archive old log files to save space on the host. Be sure to create an /ARCH directory
tar -cvzf $LPATH/ARCH/OLD_CAPTURES.gz $LPATH/*.csv
rm -rf $LPATH/*.csv
esxtop -b -c $CONFIG -d $DELAY -n $ITERATIONS > $LPATH$LOGFILE
#END
—–End of Script—
Non-Uniform Memory Access:
In a Current NUMA system such as the Intel Nehalem-based system, there are multiple NUMA nodes within a server that consist of a set of processor “Sockets” and the coinciding memory slots that are addressed by each given socket (DIMM Banks). This basically ‘splits’ the hardware – RAM bus and CPU’s into logical units that have direct access to each other. Memory can be accessed remotely to the other NUMA. The access to memory in the same NUMA node is local while the access to the other NUMA node is remote.
How many vCPUs? | More is not always better:
Virtual Machines with a total number of vCPUs that are equal to or less than the number of physical cores in each socket or local NUMA node would be considered a normalized Virtual Machine. A Virtual Machine with more vCPUs than the total cores within a given NUMA node is called a “Wide Virtual Machine” spanning both local and remote NUMA nodes. Due to potential memory access beyond a single NUMA node and out to two or more NUMA nodes, performance will suffer due to higher memory access latencies across the respective NUMA nodes.
CPU Scheduling and CoStop:
Remote NUMA node access will have longer CPU cycles due to traversing the QPI bus. Maximization of memory locality to a respective NUMA node improves performance. If CPU load-balancing is spanning NUMA nodes, CoStop counters via ESXTOP should be monitored.
What is Virtualization? What are the benefits? How well does it perform?
These are common questions about Virtualization. It is the new way of computing that allows you to gain more computing resources through the consolidation of Hardware, and maximizing hardware-based resources such as CPU, and RAM. It also offers high availibility of applications, and the ability to run multiple instances of desktops and servers within a given Desktop or Server.