virtuallyGhetto

vSphere 4.1

Did you know that VMware Host Profile is extensible by 3rd Parties?

by 1 Comment

Managing ESXi host configurations can be challenging and the potential risk for configuration drift between the running environment and the set of configuration scripts or worse, manual configuration is quite high. On top of that, how do you ensure proper compliance of all your ESXi host configurations in your environment and easily prove that in an internal or security audit?

This is where VMware Host Profile can help which allows administrators to capture the running configurations of an ESXi host and automatically creating a template (Host Profile) that can then be applied across new or existing ESXi hosts. By leveraging Host Profile, administrators can ensure that all their ESXi host configurations are always consistent and configuration drifts can easily be prevented through automatic compliance checks.

Recently, while searching for something on VMware's HCL website, I accidentally stumbled onto what appears to be 3rd party Host Profiles? There were only two listed, one from Brocade for managing and configuring Brocade storage adapters and the other from Dell for managing and configuring Dell's EqualLogic MEM (Multipathing Extension Module). I was actually quite surprise to learn about these custom 3rd party Host Profiles. In doing a bit of digging and research it turns out that VMware Host Profile are in fact extensible by design, which was something new to me.

Note: For a technical overview of Host Profile, you can take a look at this whitepaper here. 

Host Profile Architecture

Host Profile was first introduced with the release of vSphere 4.1 and the brain of the system is known as the Host Profile Engine which was part of the vCenter Server. In vSphere 5.0, Host Profile was re-architected and the Host Profile Engine was moved into the ESXi host which allowed for Host Profile Plugins to be added to an ESXi Image and expose new Host Profiles through the Host Profile Engine.

A Host Profile is actually a hierarchical composition of multiple sub-profiles and policies. Each policy defines a set of parameters that a user can select from and apply to an ESXi host. For instance, the default VMware Host Profile is composed up of 12 individual sub-profiles: authentication, datetime, firewall, memory, network, option, security, service, storage, userAccount and userGroupAccount.

With this new re-architecutre, Host Profile can be extended by 3rd party partners/vendors to create custom Host Profile Plugins to expose vendor specific hardware or software configurations and made available through a common Host Profile API/UI for customers to consume.

Host Profile Extensibility Options

To build a Host Profile Plugin, you will need to use the Host Profile SDK which is only available as part of VMware TAP (Technology Alliance Partner) Program. A Host Profile Plugin basically wraps the actual configuration work and can be backed by one of three ways:

  1. CIM Provider using the CIM SDK
  2. ESXCLI plugins
  3. Userworld binaries

As you can see, creating a Host Profile Plugin is quite flexible and can be exposed through several mechanisms. The most shocking discovery that I found was the lack of 3rd party vendor Host Profiles that exists today, especially from the big server hardware vendors. Coming from a Systems Administrator background, I would loved to have been able to configure and manage my server's firmware, BIOS, out-of-band management (iLO/DRAC), etc. through either a custom ESXCLI plugin or Host Profile Plugin. This would really benefit customers from having to manage configurations using multiple tools and allowing them centralize their management including compliance capabilities all from a single interface.

Hopefully this was an educational post for everyone and if you are a customer and would like to see certain functionality exposed by our 3rd party partners, feel free to leave a message and perhaps one of them may consider adding a custom Host Profile Plugin 🙂

VMware officially releases vibddi for vSphere 4.1

by Leave a Comment

There were several product releases last week that got a lot of buzz on the inter-tube:

However, VMware actually released an additional product last week which snuck under the radar, vibddi.

I actually wrote about this unsupported and undocumented utility last year: How to inject custom drivers into an ESXi 4.1 image using vibddi? vibddi (pronounced vib d-d-i) stands for VIB (vSphere Installation Bundle) Disk Dump Image and it is a utility to help users easily customize ESXi images with custom drivers. This utility first appeared in the vSphere Auto Deploy appliance and it looks like VMware has finally released it as an official tool to support vSphere 4.1 image customization. You also may have heard about the new Image Builder tool with the release of vSphere 5, the origins of that utility actually came from vibddi.

If you are still using vSphere 4.1 and need to inject or modify drivers, I would highly recommend you take a look at the tool as it is extremely simple to use. For more details, please check out the new VMware KB article 2003316 documenting the details of the utility or my blog post. If you are using vSphere 5, you will need to use Image Builder as vSphere 4.1 is not supported and vice-a-versa with ESXi 5 with vibddi.

Note: There are some changes in the latest vibddi utility compared to the one found in the vSphere Auto Deploy such as injecting custom kickstart configuration file or license file. If you rely on these features, you may want to use the older version or manually update these after the system build.

New Application Awareness API in vSphere 5

by 12 Comments

Application Awareness HA is not a new feature in vSphere 5, it has actually has been around since vSphere 4.1. With this feature, vSphere HA can monitor heartbeats generated from an application monitor within the guestOS and reboot the virtual machine.

What is actually new in vSphere 5 is the availability of the Application Awareness API for anyone to consume and integrate into their own application and/or script. Prior to this, the API was only exposed to ISV and 3rd party vendors with solutions such as Symantec's ApplicationHA and Neverfail's vAppHA.

The Application Awareness API (will be shorthanded as AAA, going forward) is supported in both Linux and Windows (32/64bit) and can be accessed by installing a package within the guestOS. This package includes the necessary AAA libraries to create your own program/scripts in C, C++, Java and Perl. In addition, the package also includes a pre-compiled binary (vmware-appmonitor) that implements all the AAA methods that can easily be called from within a script or program. AAA uses the VMware Tools as communication channel to the ESX(i) host and you will need to ensure VMware Tools is installed and running. Since the communication is between VMware Tools and the ESX(i) host, there is no reliance on a TCP/IP network for this communication channel.

UPDATE: You can download GuestAppMonitor SDK here.

There are currently 6 AAA methods:

  • VMGuestAppMonitor_Enable()
    • Enables Monitoring
  • VMGuestAppMonitor_MarkActive()
    • Call every 30 seconds to mark application as active
  • VMGuestAppMonitor_Disable()
    • Disable Monitoring
  • VMGuestAppMonitor_IsEnabled()
    • Returns status of Monitoring
  • VMGuestAppMonitor_GetAppStatus()
    • Returns the current application status recorded for the application, three possible values:
      • green = Virtual machine infrastructure acknowledges that the application is being monitored.
      • red = Virtual machine infrastructure does not think the application is being monitored. The
        HA monitoring agent will initialize an asynchronous reset on the virtual machine if the status is Red
      • gray = Application should send VMGuestAppMonitor_Enable again, followed
        by VMGuestAppMonitor_MarkActive, because either application monitoring failed, or the virtual machine was vMotioned to a different location
  • VMGuestAppMonitor_Free()
    • Frees the result of the *_GetAppStatus() call (only required when writing your own program)

Here is the basic workflow for using AAA within your application:

Check_if_enabled();
If not enabled, set enabled
Monitor application
If application is good, send heartbeat

Wait 15 seconds
Loop

To start using AAA functionality, you will first need to have a vSphere HA enabled cluster and enable the "VM and Application Monitoring" under VM Monitoring.

You have the ability to configure the sensitivity of AAA from Low, Medium and High which correlates to the heartbeat interval and frequency of virtual machine reboots. You also have the option of configuring your own custom policy.

Lastly, you can choose which virtual machines will be included in VM Monitoring and/or Application Monitoring.

Note: It is important to note, that HA will expect an application heartbeat to be generated every 30secs. If HA fails to receive a heartbeat within 30secs, it will transition the appHeartbeatStatus state from green to red. Depending on the configured sensitivity policy, once the heartbeat interval has been violated, HA will then restart the virtual machine. For example, if you have the sensitivity configured to medium and a heartbeat was not received within 30secs, it will change to a red state. If HA still has not received a heartbeat within 60secs of that time, then it will reboot the virtual machine.

Here is an example of installing AAA on a Linux system and compiling the C sample program:

Step 1 - Copy the AAA package to Linux system and extract the contents

Step 2 - Change into VMware-GuestAppMonitorSDK/docs/samples/C/ and ensure you have gcc compiler. You may have to change the makefile if you are on a 64bit platform as it is configured by default to point to the 32bit library. When you are ready, just type "make" and you should get compiled binary called "sample" which is the sample C application

Before you run the application, you need to ensure that your shared library path variable LD_LIBRARY_PATH has been updated to include the libappmonitorlib.so. To update the variable, you will run the following command:

LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/full/path/to/VMware-GuestAppMonitorSDK/lib64

Step 3 - You can now run the "sample" application which runs in a continuous loop and automatically enables AAA within the virtual machine and sends heartbeats to ESX(i) host. You can press control+C which then brings up three options: stop (s), disable (d), continue (c). The last two options should be pretty straight forward, but if you decide to stop the heartbeating and you don't resume, you will see HA restart the virtual machine based on your cluster configuration.

As you can see, once the heartbeats have not been received within the specified interval, HA will take action and reboot the virtual machine as expected. Here is a detail of the events as seen by vCenter and the HA cluster:

Here is an example of installing AAA on a Windows system and using the pre-compiled vmware-appmonitor binary:

Step1 - Copy the AAA package to Windows system and extract the contents 

Step 2 - Launch a cmd prompt and change into C:\Users\Administrator\Desktop\VMware-GuestAppMonitorSDK-457765\VMware-GuestAppMonitorSDK\bin\win64 directory. Depending if you are on a 32/64bit OS, you will need to modify the win{32,64}

Step 3 - Run the vmware-appmonitor.exe which will then provide you with options: enable, disable, markActive, isEnabled, getAppStatus

Note: The options in vmware-appmonitor for both Linux and Windows are exactly the same, this is very nice for consistency and scripting purposes. Just like with the direct use of the API, you need to first run the enable command to turn on Application monitoring and then run the markActive command which sends the heartbeats. You can always check the current heartbeat status by running getAppStatus or check whether AAA is enabled by running isEnabled command

As a reference, here are the paths to the vmware-appmonitor for both Linux and Windows:

  • VMware-GuestAppMonitorSDK/bin/bin{32,64}/vmware-appmonitor
  • VMware-GuestAppMonitorSDK-457765\VMware-GuestAppMonitorSDK\bin\win{32,64}\vmware-appmonitor.exe

For those of you who are not into programming languages such as C,C++ and Java, here is an example using Perl. In the example, the script simulates the monitoring of an application by checking whether or not a file exists. The script starts off by creating a file that will monitored and then loops for 5 minutes and checks for the existence of the file. Once the 5 minutes are up, the script then disables Application monitoring and exits.

Note: You will need to set the two variables at the top which define the path to the shared library and the vmware-appmonitor binary.

So far we have demonstrated on how to setup AAA within the guestOS and provided a variety of programming/scripting interfaces such as C,C++, Java and Perl to integrate with your own application/script. Now what if we wanted to extract the heartbeat status for all virtual machines that have AAA implemented going through vCenter? You can easily do so by using the vSphere API and querying the appHeartbeatStatus property of your virtual machine.

I wrote a very simple vSphere SDK for Perl script getVMAppStatus.pl that allows you to query a virtual machine connecting to either vCenter or directly to an ESX(i) host to extract the heartbeat status.

Download the getVMAppStatus.pl script here.

The script can return three different status: gray, green or red and the definition for each is defined above.

Now before you jump right in and start leveraging this awesome API in either a custom application or script, you need to understand your application and various ways on detecting that it has failed and when you would like vSphere HA to reboot the virtual machine. Simply checking whether the process is running may or may not be enough.

To get more details on some of the best practices around using the Application Awareness API, I would highly recommend you check out Tom Stephens upcoming VMworld 2011 presentation TEX1928 Implementing Application Awareness in the Web Client and The Uptime Blog for more details about implementing AAA . For now, if you would like to learn more about Application Awareness API, check out last year's VMworld presentation.

How to Send vCenter Alarm Notification to Growl

by 2 Comments

This tweet from Jason Nash and @PunchingClouds says it all and here it is!

I did some research this afternoon and stumbled upon this article Nagios: Notifications via Growl and leveraging the Net::Growl Perl module, I was able to forward alarms generated from a vCenter server to a system that was running Growl.

Software Requirements:

Step 1 -  Install Grow and configure a password under the "Security" tab and ensure you "Allow network notification"

Step 2 - Install vSphere SDK for Perl on your vCenter server. You may also need to update the PATH variable with Perl bin directory (e.g. C:\Program Files\VMware\VMware vSphere CLI\Perl\bin)

Step 3 - Install Net::Growl Perl module using ppm (Perl Package Manager) which is part of ActiveState Perl with the installation of vSphere SDK for Perl. This will require your vCenter server have internet access to ActiveState Perl site, if you can not get this access, you can install this locally on your system and extract the Growl.pm and copy it to your vCenter server C:\Program Files\VMware\VMware vSphere CLI\Perl\site\lib\Net

Step 4 - Copy the Perl script from here and store it somewhere on your vCenter server, make sure it has the .pl extension. In this example, I named it growl.pl

Step 5 - To verify that Growl Perl script works and can communicate to the system with Growl install, you can manually test it by running the following command:

growl.pl -H william.primp-industries.com -p vmware -a custom -t Alert -m "hello william" -s 1

You will need to change -H to the hostname or IP Address of the system with Growl installed and of course the password you had setup. You should see a notification of the message you had just sent.

Step 6 - Create a batch script which will call the growl.pl script and store it somewhere on your vCenter server. Here is what the script (sendGrowl.bat) looks like, you can modify it to fit your requirements.

Note: If you would like to get a list of other default VMware alarm variables, run the "SET" command and output it to a file to get more details on various variables that can be accessed.

Step 7 - Create a new or update an existing vCenter alarm and under "Actions", specify "Run a command" option and provide the full path to the sendGrowl.bat

Step 8 - For testing purposes, I created a new alarm that would trigger upon an ESX(i) host going in/out of maintenance mode and you can see from the "Tasks and Events", our script is triggered on the vCenter server

and now for the finale, you should see a notification from Growl on your system and since we enable the "sticky" parameter, the notification will stay on your screen until you click on it. You can see that in the script example, I set the message to the event and application is registered as the name of the vCenter server, which allows you to have multiple vCenter forward you notifications.

So there you have it, forwarding vCenter alarms to Growl.

Note: Once a vCenter alarm has been triggered, the script will not fire off again until the original alarm has been reset to green. This behavior probably is okay for majority of the events one would want to monitor, but if you want it to continuously alert you, you will need to fiddle with a way to reset the alarm on the vCenter server.

UPDATE:  Thanks to Richard Cardona for reminding me, but this can also be implemented on the new VCVA (vCenter Server Virtual Appliance) in vSphere 5. Here are the instructions on setting it up

Step 1 - Install Grow and configure a password under the "Security" tab and ensure you "Allow network notification" on the system that is receiving the Growl notifications

Step 2 - To install Net::Growl, we'll be using cpan which requires 2 modules that are not installed by default on the SLES VCVA. Using the Tips and Tricks for vMA 5 (running SLES as well), we'll go ahead and setup zypper package manager for VCVA to install the two required packages: make and yaml

zypper --gpg-auto-import-keys ar http://download.opensuse.org/distribution/11.1/repo/oss/ 11.1
zypper --gpg-auto-import-keys ar http://download.opensuse.org/update/11.1/ Update-11.1
zypper refresh
zypper in make
zypper in perl-YAML

Step 3 - You will use cpan to install Net::Growl

perl -MCPAN -e shell

Step 4 - Once you are inside the cpan shell, type the following to install Net::Growl

install Net::Growl

Step 5 - Copy the Perl script from here and store it somewhere on your vCenter server (e.g. /root), make sure it has the .pl extension and has execute permission. In this example, I named it growl.pl

Step 6 - To verify that Growl Perl script works and can communicate to the system with Growl install, you can manually test it by running the following command:

vcenter50-2:~ # ./growl.pl -H william.primp-industries.com -p vmware -a custom -t Alert -m "hello william" -s 1

Step 7 - Create a shell script which will call the growl.pl script and store it somewhere on your vCenter server (e.g. /root). Here is what the script (sendGrowl.sh) looks like, you can modify it to fit your requirements.

Step 8 - Create a new or update an existing vCenter alarm and under "Actions", specify "Run a command" option and provide the full path to the sendGrowl.sh

How to Persist Configuration Changes in ESXi 4.x/5.x Part 2

by 5 Comments

Continuing from part 1 of How to Persist Configuration Changes in ESXi 4.x/5.x Part 1, here is another method which I prefer when trying to persist configuration changes in ESXi. When ESXi boots up, it loads it's filesystem into memory which the modules to be loaded up are determined by the configuration found in /bootbank/boot.cfg and /altbootbank/boot.cfg for the two respective partitions (primary / backup).

UPDATE: You can now persist configuration files such as firewall rules and others using the new VIB Author Fling, please take a look at this article for more details.

Here is an example of ESXi 4.x default boot.cfg:

~ # cat /bootbank/boot.cfg
kernel=b.z
kernelopt=
modules=k.z --- s.z --- c.z --- oem.tgz --- license.tgz --- m.z --- state.tgz --- vpxa.vgz
build=4.1.0-348481
updated=1
bootstate=0

Here is an example of ESXi 5.x default boot.cfg:

~ # cat /bootbank/boot.cfg
bootstate=0
kernel=tboot.b00
title=Loading VMware ESXi
kernelopt=no-auto-partition
modules=b.b00 --- useropts.gz --- k.b00 --- a.b00 --- ata-pata.v00 --- ata-pata.v01 --- ata-pata.v02 --- ata-pata.v03 --- ata-pata.v04 --- ata-pata.v05 --- ata-pata.v06 --- ata-pata.v07 --- block-cc.v00 --- ehci-ehc.v00 --- s.v00 --- ima-qla4.v00 --- ipmi-ipm.v00 --- ipmi-ipm.v01 --- ipmi-ipm.v02 --- misc-cni.v00 --- misc-dri.v00 --- net-be2n.v00 --- net-bnx2.v00 --- net-bnx2.v01 --- net-cnic.v00 --- net-e100.v00 --- net-e100.v01 --- net-enic.v00 --- net-forc.v00 --- net-igb.v00 --- net-ixgb.v00 --- net-nx-n.v00 --- net-r816.v00 --- net-r816.v01 --- net-s2io.v00 --- net-sky2.v00 --- net-tg3.v00 --- ohci-usb.v00 --- sata-ahc.v00 --- sata-ata.v00 --- sata-sat.v00 --- sata-sat.v01 --- sata-sat.v02 --- sata-sat.v03 --- scsi-aac.v00 --- scsi-adp.v00 --- scsi-aic.v00 --- scsi-bnx.v00 --- scsi-fni.v00 --- scsi-hps.v00 --- scsi-ips.v00 --- scsi-lpf.v00 --- scsi-meg.v00 --- scsi-meg.v01 --- scsi-meg.v02 --- scsi-mpt.v00 --- scsi-mpt.v01 --- scsi-mpt.v02 --- scsi-qla.v00 --- scsi-qla.v01 --- uhci-usb.v00 --- imgdb.tgz --- state.tgz
build=5.0.0-441354
updated=1

As we learned from the previous article, the cron'd /sbin/auto-backup.sh generates a local.tgz which is then converted to state.tgz which contains all files automatically backed up by VMware. This file is loaded up along with other modules as part of the boot process. Understanding this, allows us to take advantage of this feature for persisting our own configuration files.

Here is an example use case for creating .ssh directory for SSH keys and persisting a script
(ghettoVCB.sh) in /bin for an ESXi 4.x host:

Step 1 - Re-create the modified directory structure and files in a temporary local path which will then be tarred and gzip. An example would be the following:

Actual change:
/.ssh/authorized_keys
/bin/ghettoVCB.sh

Temporary local directory structure of change:
/tmp/.ssh/authorized_keys
/tmp/bin/ghettoVCB.sh

Note: It is very important to ensure that the modified files get the stickybit permission set. As noted in the last article that upon a change, the visorFS will automatically create a special file to denote it for backup but also it allows the file to be writable at some later point for custom files being added.

Step 2 - You will use the tar utility to tar/gzip the contents in a file with extension .tgz. One thing to note, the file name including the extension must not exceed 12 characters. In our example, we made two changes and re-created the local structure under /tmp. We will need to change into /tmp directory and tar up the contents by using the following command:

/tmp # tar -czvf ghetto.tgz .ssh/ bin/
.ssh/
.ssh/authorized_keys
bin/
bin/ghettoVCB.sh

Now you should have the contents of .ssh and bin within your *.tgz file. To verify and view the contents, you can run the following command:

/tmp # tar -tzvf ghetto.tgz
drw------- 0/0 0 2011-08-10 04:10:11 .ssh/
-rw------T 0/0 399 2011-08-10 04:10:11 .ssh/authorized_keys
drwxr-xr-x 0/0 0 2011-08-10 04:10:24 bin/
-rwxr-xr-t 0/0 46973 2011-08-10 04:10:24 bin/ghettoVCB.sh

Step 3 - Next we need to copy the *.tgz file into /bootbank and modify the /bootbank/boot.cfg to ensure our new module is included in the boot up process

cp /tmp/ghetto.tgz /bootbank

Here is what the modified ESXi 4.x boot.cfg should look like after:

kernel=b.z
kernelopt=
modules=k.z --- s.z --- c.z --- oem.tgz --- license.tgz --- m.z --- state.tgz --- vpxa.vgz --- ghetto.tgz
build=4.1.0-348481
updated=1
bootstate=0

The next time you reboot the system, you will automatically have your .ssh directory containing your SSH keys and the ghettoVCB script under /bin directory.

Now this is great for an inline modification, but what about creating custom configuration files and including that as part of a default kickstart installation? What about something like custom firewall rules in ESXi 5? In the following example, we'll include a custom firewall rule called "virtuallyGhetto.xml" which will be stored in /etc/vmware/firewall when the contents of the module is extracted.

Step 1 - We of course need to create the XML file containing the firewall rule and create the directory structure in which it will be unloaded to.

/tmp/etc/vmware/firewall/virtuallyGhetto.xml

Step 2 - Next we'll tar up the local contents

[[email protected] tmp]# tar -zcvf ghetto.tgz etc/
etc/
etc/vmware/
etc/vmware/firewall/
etc/vmware/firewall/virtuallyGhetto.xml

Step 3 - This new package will need to be stored on you installation server which will be reachable via http using wget and as part of the %firstboot stanza in your ESXi 5 kickstart. It will download the *.tgz file and append the entry in /bootbank/boot.cfg configuration file. Here are the entries that should go into your kickstart:

# Adding custom files to boot argument (e.g. custom firewall rules,etc)

wget http://air.primp-industries.com/esxi5/ghetto.tgz -O /bootbank/ghetto.tgz
sed -e '/modules=/s/$/ --- ghetto.tgz/' -i /bootbank/boot.cfg

Note: If you add custom files that are located under /etc and you have the stickybit enabled on your file, changes made will persist upon the next reboot by either manually running /sbin/auto-backup.sh or letting it run via cron. If you add custom files that are not located under /etc, any change you make must be periodically updated in your custom *.tgz file else the next reboot, the original file will be loaded.

How to Create and Modify vgz (vmtar) Files on ESXi 3.x/4.x

by 4 Comments

There were several questions today on the VMTN community forums with regards to manipulating .vgz files in ESXi, also known as vmtar files. Due to the sparse amount of information on the web, I wanted to document some of the common operations that can be performed on the vmtar files. I will not be going over the use cases for manipulating or creating custom vmtar files, but here is one use case.

UPDATE (10/16/18) - For ESXi 6.5+, please use the following commands and the example below is using the s.v00 file:

Decompress file:

gunzip < s.v00 > s.v00.xz
xz --single-stream --decompress < s.v00.xz > s.v00.vtar
vmtar -v -x s.v00.vtar -o s.v00.tar
tar -xvf s.v00.tar

Compress file:

tar -cvf s.v00-new.tar bin/ etc/ lib/ lib64/ opt/ usr/ var/
vmtar -v -c s.v00.tar -o s.v00.vtar
xz --single-stream --compress < s.v00.vtar > s.v00.xz
xz --single-stream --compress < s.v00.vtar > s.v00

You can find some of these vmtar files with .vgz extension in the ESXi installation iso, here are a few highlighted in red:

To operate on existing vmtar files, you will need access to an ESXi host via ESXi Shell and using the /sbin/vmtar utility.

Usage: vmtar {[-x vtar/vgz-file] [-c tar/tgz-file] [-v] -o destination} | -t < vtar/vgz-file

In this example, we will copy the install.vgz to an ESXi host to perform some operations.

To list the contents of a vmtar file, you will need to use the -t option:

To extract the contents of vmtar file, you will need to use the -x and -o option:

vmtar -x install.vgz -o install.tar

Note: The output will be a standard tar file which will then need to be extracted before getting to the actual contents

To extract the tar file, we will be using the tar utility:

Let's say we made a change to one of the files and now we would like to re-create the vmtar file, we will first need to tar up the contents by using the tar utility again:

To verify the contents were all tarred up, we can view the contents by using the following command:

tar -tf install.tar

Now we will create the vmtar file using the vmtar utility:

vmtar -c install.tar -o install.vgz

We can confirm the contents by using vmtar -t option once again:

vmtar -t < install.vgz

If you decide to create your own custom vmtar files and want to verify the file layout, you can use vmkramdisk to assist you. Using vdf command, make note of the number of tardisks that have been mounted up.

Also make note of the filesystem layout by performing an "ls" on / (slash):

Now let's say you wanted to create a directory called virtuallyGhetto with a file in that directory called foobar and you wanted it to be mounted up under /

Here are the steps to perform the above:

Do you notice anything different? How about performing an "ls" on / (slash) again?

To umount the vmtar disk, you would use the following command:

vmkramdisk -u virtuallyGhetto.vgz