These are the changes in version 3.2:

• New tabpage with distributed switch information
• New tabpage with distributed port information
• It’s now possible to export a single tabpage to an excel file from the command line
• It’s now possible to save the filter. The next time RVtools is started it will use the filter automatically.
• Bugfix: On vSnapshot tab the displayed filename and filesize are not always correct
• Bugfix: Improved exception handling on vPort tab

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!

ESXiStateless.zip 137,869 KB

Now the first thing to do was figuring out which VIBs were part of this image profile, you can do this fairly simple by using the command below. Note that I exported the results to a CSV file just to make it easier if I would need to add VIBs later:

Get-EsxImageProfile <image profile name>  | Select-Object -ExpandProperty VibList | Select name | export-csv c:\tmp\VIBs.csv


Now this returns the full list of all the VIBs in a CSV file with just the names of the VIBs. There are 2 core VIBs (esx-base and esx-tboot) which are required for booting. I also kept the e1000 VIB as I knew I needed it. The e1000 VIB requires the “misc-drivers” VIB so I was left with 4 VIBs:

esx-base
esx-tboot
e1000
misc-drivers

Stripping the rest of the VIBs is fairly simple. Note that you will need to replace <image profile name> with the actual name of your image profile and <package name> with the name of the package you would like to remove:

Remove-EsxSoftwarePackage -ImageProfile <image profile name> -SoftwarePackage <package name>

So I stripped it completely and exported the image profile again and this was the result:

Thinner.zip 131,457 KB

Note that you can actually check which VIBs are part of your image profile, which is what I used to validate I removed all unnecesarry VIBs:

Get-esximageprofile <image profile name> | Select-Object -ExpandProperty VibList

That is a whopping 6MB shaved off! (By the way this is without the HA-Agent. The size of the completely stripped image profile with the HA agent is 143,679KB) Was it a useful exercise? Yes it was as it helped me understanding the process a lot better… Is it useful to strip all the drivers from your image profile? No it is not, you will only save 6MB which is close to nothing compared to the overall size of 131 MB. I did manage to boot the image correctly, but once again there’s really no point from a memory perspective to go through this exercise.

The thing that does make a huge difference is using the no-tools image profile, but there is a serious implication. When you do not include VMware Tools you will need to have a different mechanism for distributing VMware Tools which will probably complicate things from an operational perspective. I guess you will need to decide if the reduction in MBs is worth the effort and is worth the risk of having a “1 of a kind” environment. I know I will keep it vanilla from now on,

1. Live Blog: Raising The Bar, Part V
2. 5 is the magic number
3. Hot of the press: vSphere 5.0 Clustering Technical Deepdive
4. vSphere 5.0: Storage DRS introduction
5. vSphere 5.0: What has changed for VMFS?
6. vSphere 5.0: Storage vMotion and the Mirror Driver
7. Punch Zeros
8. Storage DRS interoperability
9. vSphere 5.0: UNMAP (vaai feature)
10. vSphere 5.0: ESXCLI
11. ESXi 5: Suppressing the local/remote shell warning
12. Testing VM Monitoring with vSphere 5.0
13. What’s new?
14. vSphere 5:0 vMotion Enhancements
15. vSphere 5.0: vMotion enhancement, tiny but very welcome!
16. ESXi 5.0 and Scripted Installs
17. vSphere 5.0: Storage initiatives
18. Scale Up/Out and impact of vRAM?!? (part 2)
19. HA Architecture Series – FDM (1/5)
20. HA Architecture Series – Primary nodes? (2/5)
21. HA Architecture Series – Datastore Heartbeating (3/5)
22. HA Architecture Series – Restarting VMs (4/5)
23. HA Architecture Series – Advanced Settings (5/5)
24. VMFS-5 LUN  Sizing
25. vSphere 5.0 HA: Changes in admission control
26. vSphere 5 – Metro vMotion
27. SDRS and Auto-Tiering solutions – The Injector

Once again if there it something you feel I should be covering let me know and I’ll try to dig in to it. Preferably something that none of the other blogs have published of course.

There’s a new component that is part of vMotion which is only enabled with Enterprise Plus and that components is what we call ‘Metro vMotion’.  This feature enables you to safely vMotion a virtual machine across a link of up to 10 miliseconds RTT. The technique used is common practice in networking and a bit more in-depth described here.

In the case of vMotion the standard socket buffer size is around 0.5MB.  Assuming a 1GbE network (or 125MBps) then bandwidth delay product dictates that we could support roughly 5ms RTT delay without a noticeable bandwidth impact.  With the “Metro vMotion” feature, we’ll dynamically resize the socket buffers based on the observed RTT over the vMotion network.  So, if you have 10ms delay, the socket buffers will be resized to 1.25MB, allowing full 125MBps throughput.  Without “Metro vMotion”, over the same 10ms link, you would get around 50MBps throughput.

Is that cool or what?

With ESXi 5.0 this has been simplified, this is what it looks like today:

I also want to point out that many of the standard installation commands have been replaced, removed or are not supported anymore. I created a simple script to automatically install an ESXi 5.0 host. It creates a second vSwitch and a second VMkernel for vMotion. It enables both the local and remote TSM and sets the default PSP for the EMC VMAX to Round Robin. As you can see there is a huge shift in this script towards esxcli. Although some of the old “esxcfg-*” commands might still be working they are deprecated and no longer supported. The new standard is esxcli, make sure you get familiarized with it and start using it today as over time this will be the only CLI tool available.


# Sample scripted installation file
# Accept the VMware End User License Agreement
vmaccepteula
# Set the root password for the DCUI and ESXi Shell
rootpw mypassword
# Install on the first local disk available on machine
install --firstdisk --overwritevmfs
# Set the network to DHCP on the first network adapater, use the specified hostname and do not create a portgroup for the VMs
network --bootproto=dhcp --device=vmnic0 --addvmportgroup=0
# reboots the host after the scripted installation is completed
reboot

%firstboot --interpreter=busybox
# Add an extra nic to vSwitch0 (vmnic2)
esxcli network vswitch standard uplink add --uplink-name=vmnic2 --vswitch-name=vSwitch0
#Assign an IP-Address to the first VMkernel, this will be used for management
esxcli network ip interface ipv4 set --interface-name=vmk0 --ipv4=192.168.1.41 --netmask=255.255.255.0 --type=static
# Add vMotion Portgroup to vSwitch0, assign it VLAN ID 5 and create a VMkernel interface
esxcli network vswitch standard portgroup add --portgroup-name=vMotion --vswitch-name=vSwitch0
esxcli network vswitch standard portgroup set --portgroup-name=vMotion --vlan-id=5
esxcli network ip interface add --interface-name=vmk1 --portgroup-name=vMotion
esxcli network ip interface ipv4 set --interface-name=vmk1 --ipv4=192.168.2.41 --netmask=255.255.255.0 --type=static
# Enable vMotion on the newly created VMkernel vmk1
vim-cmd hostsvc/vmotion/vnic_set vmk1
# Add new vSwitch for VM traffic, assign uplinks, create a portgroup and assign a VLAN ID
esxcli network vswitch standard add --vswitch-name=vSwitch1
esxcli network vswitch standard uplink add --uplink-name=vmnic1 --vswitch-name=vSwitch1
esxcli network vswitch standard uplink add --uplink-name=vmnic3 --vswitch-name=vSwitch1
esxcli network vswitch standard portgroup add --portgroup-name=Production --vswitch-name=vSwitch1
esxcli network vswitch standard portgroup set --portgroup-name=Production --vlan-id=10
# Set DNS and hostname
esxcli system hostname set --fqdn=esxi5.localdomain
esxcli network ip dns search add --domain=localdomain
esxcli network ip dns server add --server=192.168.1.11
esxcli network ip dns server add --server=192.168.1.12
# Set the default PSP for EMC V-MAX to Round Robin as that is our preferred load balancing mechanism
esxcli storage nmp satp set --default-psp VMW_PSP_RR --satp VMW_SATP_SYMM
# Enable SSH and the ESXi Shell
vim-cmd hostsvc/enable_ssh
vim-cmd hostsvc/start_ssh
vim-cmd hostsvc/enable_esx_shell
vim-cmd hostsvc/start_esx_shell


For more deepdive information read William’s post on ESXCLI and Scripted Installs.

VMware ESXi Operations Guide

Learn how to perform common datacenter tasks in your ESXi environment by seeing the operational differences from the legacy ESX architecture.

Download Operations Guide

Another whitepaper I wanted to point out is the ESXi Migrations Guide. It has been written by my colleague Kyle Gleed and is an excellent start for those looking to migrate from ESX to ESXi in the near future. Not only is the whitepaper very useful, but I am also confident you will appreciate the checklists and the configuration sheet which will help with a smooth transition.

VMware ESXi Migration Guide

Learn how to plan and perform your migration to the ESXi architecture from the legacy ESX framework, with helpful checklists for organizing the steps involved.

Download Migration Guide

Download Migration Checklists

Download Host Configuration Worksheet

We are also working on automating some parts of the upgrade, and I hope to be able to publish an update on that soon.

After having several discussions with customers, fellow consultants and engineers we managed to figure out why this perception was floating around. The answer was actually fairly simple and it is metrics. When monitoring memory most people look at the following section of the host – summary tab:

However, in the case of large pages this metric isn’t actually that relevant. I guess that doesn’t only apply to large pages but to memory monitoring in general, although as explained it used to be an indication.  The metric to monitor  is “active memory“. Active memory is is what the VMkernel believes is currently being actively used by the VM. This is an estimate calculated by a form of statistical sampling and this statistical sampling will most definitely come in handy when doing capacity planning. Active memory is in our opinion what should be used to analyze trends, monitor capacity etc. I guess it is not a coincidence that almost every capacity planning or monitoring tool out there uses this metric. (Cap IQ, VC Ops etc) Kit Colbert has also hammered on this during his Memory Virtualization sessions at VMworld. I guess the following screenshot is an excellent example of the difference between “consumed” and “active”. Do we need to be worried about “consumed” well I don’t think so, monitor “active”!

Anyway, I gave the PowerCLI Reference Book 5 stars as I truly believe it is one of a kind, here’s my justification for it:

I received the paper-version of the book last week and started reading it straight away. The authors are THE number one PowerCLI experts in the world and take you through the trenches of vSphere automation.
Although I know vSphere inside out I am a novice when it comes to PowerCLI. The main reason being that I never gave myself the time to actually learn PowerCLI as I figured I could do things faster using the UI. Although this might be true in some cases the first thing the book tought me was that my perception was wrong. The book shows you how to optimize your day-to-day operations by taking advantage of what PowerCLI has to offer out of the box, but it also teaches you how to create your own functions. The amount of examples in there in terms of PowerCLI scripts are such a valuable asset that I would highly recommend it to anyone who is interested in learning PowerCLI and/or optimizing their operational procedures. We are not talking about reporting only, for instance configuring vSwitches or restricting the amount of snapshots is all shown in this book. Be warned though, don’t expect a step-by-step Learning PowerCLI Guide, this is 700+ pages of pure PowerCLI automation at its best which will enable you to get the most out of your environment.

Not included on Amazon, but I do feel it would have been nice if the structure of the book was slightly different. I would have personally started with an Introduction chapter, followed “in-box” reporting functionality and finishing it off with deepdive functions and pages of script. But than again, this is a reference book and not course material. All in all, this book is more than worth it.

You can buy it here if you are interested.
(yes it contains an affiliate link)

Version 3.1 (April, 2011)

• Logon form tab order rearranged
• Logon form will remember your last selected host / vCenter server
• On vInfo new fields Provisioned, Used and shared storage
• On vInfo new fields install Boot Required, number of Virtual Disks
• On vInfo new fields Fault Tolerance State,  FT Latency Status, FT Band width and FT Secondary Latency
• On vInfo new field 128-bit SMBIOS UUID of the virtual machine.
• On vDatastore new fields Total provisioned, Used and shared storage
• On vDatastore new fields SIOC enabled flag and congested threshold value
• On vDisk new field disk persistence mode.
• On vNetwork all IP addresses of adapter are now visible
• On vMemory new field distributed Memory Entitlement
• On vCPU new fields static Cpu Entitlement and field distributed Cpu Entitlement
• On vHost new fields Current EVC mode and Max EVC mode
• New batch command line parameters -u user and -p password
• Bugfix: custom fields not always visible on vSnapshot tab.
• Bugfix: Export to Excel, some numeric columns are saved as text instead of numbers
• RVToolsBatch.cmd with send by email example deployed in RVTools program file directory