The Auto-Deploy GUI fling is an 8MB download and allows you to configure auto-deploy without the need to use PowerCLI. It comes with a practical deployment guide which is easy to follow and should allow all of you to test this in your labs! Download it it now and get started!

source
The Auto Deploy GUI is a vSphere plug-in for the VMware vSphere Auto Deploy component. The GUI plug-in allows a user to easily manage the setup and deployment requirements in a stateless environment managed by Auto Deploy. Some of the features provided through the GUI include the ability to add/remove Depots, list/create/modify Image Profiles, list VIB details, create/modify rules to map hosts to Image Profiles, check compliance of hosts against these rules and re-mediate hosts.

<live-install-allowed>true</live-install-allowed>
<live-remove-allowed>true</live-remove-allowed>

In other words, I am allowed to install it without a reboot and remove it without a reboot. Simple huh? Of course I tested it and this is the result:

~ # esxcli software vib install -v /test.vib
Installation Result
   Message: Operation finished successfully.
   Reboot Required: false
   VIBs Installed: Duncan_bootbank_firewallrule_1.0
   VIBs Removed:
   VIBs Skipped:
~ #

After clicking refresh in the vCenter client the firewall rule I created pops up as expected.

Now if you would like to know before installing what the package contains and what the requirements are you can simply figure that out by doing the following:

~ # esxcli software sources vib get -v file:/test.vib
Duncan_bootbank_firewallrule_1.0
   Name: firewallrule
   Version: 1.0
   Type: bootbank
   Vendor: Duncan
   Acceptance Level: CommunitySupported
   Summary: Firewall rule
   Description: Firewall rule
   Release Date: 2011-06-01
   Depends:
   Conflicts:
   Replaces:
   Provides:
   Maintenance Mode Required: False
   Hardware Platforms Required:
   Live Install Allowed: True
   Live Remove Allowed: True
   Stateless Ready: False
   Overlay: False
   Tags: driver, module
   Payloads: test
~ #

As you can see in this case, “live install allowed” is set to true. The vendor is “Duncan” and the Acceptance Level is “CommunitySupported”, these are important details in my opinion! Another one to keep an eye on is if the package is “Stateless Ready” or not. In my case I defined it as “false”.

Of course you can also remove a VIB file after installing it. This is pretty straight forward, first of all list all the installed VIBs:

~ # esxcli software vib list
Name                  Version                             Vendor  Acceptance Level  Install Date
--------------------  ----------------------------------  ------  ----------------  ------------
ata-pata-amd          0.3.10-3vmw.500.0.0.456551          VMware  VMwareCertified   2011-06-06
ata-pata-atiixp       0.4.6-3vmw.500.0.0.456551           VMware  VMwareCertified   2011-06-06
ata-pata-cmd64x       0.2.5-3vmw.500.0.0.456551           VMware  VMwareCertified   2011-06-06

After listing all installed VIBs you can easily remove them by using the following command:

~ # esxcli software vib remove -n ata-pata-amd

This would remove the VIB named “ata-pata-amd”. You could even do a “dry-run” to see what the result would be:

~ # esxcli software vib remove -n ata-pata-amd --dry-run
Removal Result
   Message: Dryrun only, host not changed. The following installers 
   will be applied: [BootBankInstaller]
   Reboot Required: true
   VIBs Installed:
   VIBs Removed: VMware_bootbank_ata-pata-amd_0.3.10-3vmw.500.0.0.456551
   VIBs Skipped:
~ #

I hope this provides some more details around how to handle VIB files. Don’t hesitate to leave a comment if you have any questions at all.

The tool / fling was designed specifically to help people migrate from ESX to ESXi and to smoothen the transition especially in those environments where the Service Console was customized over the years. If you haven’t migrated yet, and want to make the jump to a lean and mean hypervisor I suggest to take a look at this fling and analyze your environment to help with planning the transition!

Source: VMware Labs

The ESX System Analyzer is a tool designed to help administrators plan a migration from ESX to ESXi. It analyzes the ESX hosts in your environment and, for each host, collects information on factors that pertain to the migration process:

• Hardware compatibility with ESXi
• VMs registered on the ESX host, as well as VMs located on the host’s local disk
• Modifications to the Service Console
  • RPMs which have been added or removed
  • Files which have been added
  • Users and cronjobs which have been added

This tool also provides summary information for the whole existing environment

• Version of VMware Tools and Virtual Hardware for all VMs
• Version of Filesystem for all datastores

By having this information, administrators can determine what tasks need to be done prior to the migration. Examples include:

• Relocate VMs from local datastores to shared datastores
• Make note of what agent software has been added to the host and obtain the equivalent agentless version
• Replace cronjobs with equivalent remote scripts written with PowerCLI or vCLI

Today I was asked the question on how to create a VIB file (.vib). In our documentation it is mentioned that you can create a VIB file to add firewall rules to your ESXi host. As the .vib tool is not available yet to the general public I decided to dig in to it. I want to stress that I tested this in my own lab, it is not supported at all, but might give a nice insight in how these VIB are constructed. Before you read how I created my own VIB file I suggest reading this excellent article on what a .vib file is and contains by my colleague Kyle Gleed.

First thing I did was download an existing VIB file. I downloaded a tiny LSI SCSI driver. I did a “more” of the .vib file and I noticed the following:

!<arch>
debian-binary

That was my first lead, it appears to be a debian-binary, which is a format that the Linux distribution Debian uses to package software / drivers etc. I knew it should be possible to check what was included in this package. So I did a quick search and stumbled on some procedures on how to do this using some standard commands provided by my Debian virtual machine. (Links at the bottom) So I did the following on the package I downloaded:

ar tv file.vib

This showed me that the .vib file contained three files:

descriptor.xml
sig.pkcs7
scsi-meg

This seemed pretty obvious to me after reading Kyle’s article. The descriptor contained the metadata, the “sig*” file contained the signature and the “scsi-meg” was the actual driver. I decided to extract the VIB file to look at the content of these files:

ar vx file.vib

As the permissions on the files didn’t allow me to look at them I changed the permissions on those by using “chmod”. Now what? Well let’s look at the “scsci-meg” file first. What is it? I looked at what was in the file by using the following command:

tar -tzvf scsi-meg

It contained a list of files and that is it. I decided to extract it using “tar -xzvf” and as expected it was the folder structure and files part of this driver. I figured that it wouldn’t be too difficult to create a simple package. Why not try it… Here we go. First I deleted everything in the “sig.pkcs7″ file. As Kyle mentioned in his article that community support packages can have an empty signature. I also deleted all the files and folders that were extracted from the “scsi-meg” package that I did not need. I then created a folder underneath the “/etc/vmware” structure as I wanted to create a firewall rule. (Added the folder “firewall”.)

I copied a firewall rule from my existing ESXi host and which is created by HA to my Debian VM and edited the file, the original file was “fdm.xml”. I edited and and renamed it to test.xml. I changed all ports to 7000 and changed the <id> of the service that would need to be added and saved the file in “etc/vmware/firewall”.

Now it was time to package it all up and see if it would work. I guessed that the steps required would simply be the reverse of what I did to extract it all.

tar -czvf etc/ test

I then opened up the descriptor.xml file and changed some of the fields around, most don’t seem to matter much except for the following:

Change the following key to:
<acceptance-level>certified</acceptance-level>
<acceptance-level>community</acceptance-level>

Add your list of files:
<file-list>
<file>path-to-file</file>
</file-list>

Change the name of your package and the size accordingly:
<payload name="test" type="vgz" size="809">

I wasn’t sure if that would work, but I would find out eventually I guess (yes I also tried “communitysupport” as the acceptance-level but that doesn’t work!). I also removed the checksum details from the descriptor file just in case it would be used. This is what my full descriptor file looked like:

<vib version="5.0">
<type>bootbank</type>
<name>firewallrule</name>
<version>1.0</version>
<vendor>Duncan</vendor>
<summary>Firewall rule</summary>
<description>Firewall rule</description>
<release-date>2011-06-01T22:16:31.062257+00:00</release-date>
<urls/>

<relationships>
<depends>
</depends>
<conflicts/>
<replaces/>
<provides/>
<compatibleWith/>
</relationships>

<software-tags>
<tag>driver</tag>
<tag>module</tag>
</software-tags>

<system-requires>
<maintenance-mode>true</maintenance-mode>
</system-requires>

<file-list>
<file>etc/vmware/firewall/test.xml</file>
</file-list>

<acceptance-level>community</acceptance-level>
<live-install-allowed>false</live-install-allowed>
<live-remove-allowed>false</live-remove-allowed>
<cimom-restart>false</cimom-restart>
<stateless-ready>false</stateless-ready>
<overlay>false</overlay>

<payloads>
<payload name="test" type="vgz" size="809">
</payload>
</payloads>
</vib>

Next up would be making a single .vib file out of these three components again:

ar -r test.vib test descriptor.xml sig.pkcs7

Now I need to ‘scp’ the file to my ESXi host and see if I can install it:

scp test.vib root@esxi:test.vib

esxcli software vib install -v /test.vib

I received an error that the ImageProfile acceptance level needed to be changed. That was my next step:

esxcli software acceptance set --level CommunitySupported

After repeating the “esxcli software vib install” command I received the following output:

~ # esxcli software vib install -v /test.vib
Installation Result
   Message: The update completed successfully, but the system needs to be rebooted for the changes to be effective.
   Reboot Required: true
   VIBs Installed: Duncan_bootbank_firewallrule_1.0
   VIBs Removed:
   VIBs Skipped:
~ #

I rebooted the host and here’s a screenshot of the ESXi firewall with the newly added custom service “Test”:

Once again, I want to point out that this is currently unsupported. Don’t use this in your production environment!

The following articles helped me figuring this out and producing this article:

http://tldp.org/HOWTO/html_single/Debian-Binary-Package-Building-HOWTO/

http://linuxtrove.com/wp/?p=78

• List all VMs registered to this host (This reveals the Vmid needed for other commands)
  vim-cmd /vmsvc/getallvms
• Unregister a VM
  vim-cmd /vmsvc/unregister <Vmid>
• Register a VM
  vim-cmd /solo/register /path/to/file.vmx
• Get power state of a VM
  vim-cmd /vmsvc/power.getstate <Vimid>
• Power off a VM
  vim-cmd /vmsvc/power.off <Vmid>
• Power on a VM
  vim-cmd /vmsvc/power.on <Vmid>

This is what the log file would typically look like:

iscsid: cannot make a connection to 192.168.1.20:3260 (101,Network is unreachable)
iscsid: Notice: Reclaimed Channel (H34 T0 C1 oid=3)
iscsid: session login failed with error 4,retryCount=3
iscsid: Login Target Failed: iqn.1984-05.com.dell:powervault.md3000i.6002219000a14a2b00000000495e2886 if=iscsi_vmk@vmk8 addr=192.168.1.20:3260 (TPGT:1 ISID:0xf) err=4
iscsid: Login Failed: iqn.1984-05.com.dell:powervault.md3000i.6002219000a14a2b00000000495e2886 if=iscsi_vmk@vmk8 addr=192.168.1.20:3260 (TPGT:1 ISID:0xf) Reason: 00040000 (Initiator Connection Failure)

This is explained in KB 2007108 which also contains the download link. Make sure to download it and update your environment if you are running iSCSI.

vim-cmd hostsvc/net/query_networkhint

The one thing that I find it very useful for is to check the configured VLAN(s) on the port. Below is the result of the above command:

(vim.host.PhysicalNic.NetworkHint) [
(vim.host.PhysicalNic.NetworkHint) {
dynamicType = ,
device = "vmnic0",
subnet = (vim.host.PhysicalNic.NetworkHint.IpNetwork) [
(vim.host.PhysicalNic.NetworkHint.IpNetwork) {
dynamicType = ,
vlanId = 3001,
ipSubnet = "10.91.34.1-10.91.35.254",
},
(vim.host.PhysicalNic.NetworkHint.IpNetwork) {
dynamicType = ,
vlanId = 2912,
ipSubnet = "10.91.32.1-10.91.32.63",
}
],
connectedSwitchPort = (vim.host.PhysicalNic.CdpInfo) null,
lldpInfo = (vim.host.PhysicalNic.LldpInfo) null,
},
]

There’s a KB article on this topic http://kb.vmware.com/kb/2006859, if you are interested I would suggest bookmarking it or subscribing to it.

I want to point out though that you can run Windows 8 in Workstation 8 or Fusion 4. Yes I know that these are paid products, but you can download the eval version which is valid for 30 days. Workstation 8 comes with VMware Player 4.0, which is completely free! (Not available as a separate download yet unfortunately.)

Installing Windows 8 is straight forward, just use the Windows 7 – 64 Bit profile that is part of both Fusion and Workstation.

Add-EsxSoftwareDepot -DepotUrl https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml

If you would do a “Get-EsxImageProfile” next you would see all image profiles (see screenshot below) which are part of the depot.

Now you could even compare the two image profiles which would tell you if the image profiles are equal and which VIB has changed. In this case it is one of the primary VIBs “esx-base”:

Compare-EsxImageProfile ESXi-5.0.0-469512-no-tools ESXi-5.0.0-20110904001-notools

Equal               : False
PackagesEqual       : False
RefAcceptanceLevel  : PartnerSupported
CompAcceptanceLevel : PartnerSupported
OnlyInRef           : {}
OnlyInComp          : {}
UpgradeFromRef      : {VMware_bootbank_esx-base_5.0.0-0.3.474610}
DowngradeFromRef    : {}

If you figure by now that all this PowerCLI stuff is not your cup of tea I would like to suggest to check out Alan Renouf’s brand new PowerPack. Alan has GUI’fied the most common tasks which will enable you to click and point instead.

While I was playing around I decided to do things in an incorrect order to see if I could break it, and of course I did manage to break it… I managed to fix all of it though. The first thing I did was testing the rule set and repairing it as documented below.

Now if you run into any issues you can repair the ruleset by using the following command:

Get-VMHost <esxi host> | Test-DeployRuleSetCompliance | Repair-DeployRuleSetCompliance

Now if your host boots and mentions that there’s no rule associated you might want to try the following:

Get-DeployRule

If your newly created rule is returned you will want to make sure it is active:

Get-DeployRuleSet

If there’s nothing listed it means no rules are currently active (active ruleset is what the documentation will refer to). You you can set the rule as active as follows:

Set-DeployRuleSet -DeployRule <name of rule>

Everyone who is considering using Auto-Deploy I would most definitely recommend to explore these commands and to try to break things and fix it. Document your steps along the way, I am certain it will be valuable at some point!