Management & Automation

Cool tool: RVTools 3.2 released

Duncan Epping · Oct 29, 2011 ·

Today Rob de Veij released an update of his excellent tool called RVTools. We are up to version 3.2 already. You can find the update on the RVTools website. RVTools is an essential tool for every vSphere Admin. It allows you to report on the most important aspects of your virtual infrastructure, but probably the most important ones are limits / reservations / VMware tools. Seriously give it a try and you will be surprised with what you might find. I have used it in many environments and always managed to discover inconsistencies… Thanks again for the great work Rob!

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

Patching your Image Profile (stateless ESXi)

Duncan Epping · Sep 14, 2011 ·

The first patch for ESXi has been released so I figured this was a great time to create and article around how to patch your Image Profile with a new update. The process is fairly straight forward as in this case you will need to create a new image-profile (described here) and link it to a new rule (New-DeployRule and make that rule active (Add-DeployRule). That is what I like about Stateless. You can just prepare a new Image Profile, create a new rule and you are good to go. A reboot of your ESXi host will load up the latest Image Profile. I did this within a couple of minutes and I’m now running build 474610 of ESXi.

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!

Stripping your Stateless image

Duncan Epping · Sep 9, 2011 ·

I was just playing around with Stateless again, aka auto-deploy, and I was wondering how far I could strip the image down to the bare minimum and what the difference would be. I loaded the standard software depot and cloned an existing image profile to a new image profile, for more details on how to do this check the post I published a couple of days ago. I figured I would export this newly create image profiles first so I could see the size of the bundle when exported. I cloned and exported the “ESXi-5.0.0-469512-no-tools” image profile and checked the details:

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,

vSphere 5 Coverage

Duncan Epping · Aug 6, 2011 ·

I just read Eric’s article about all the topics he covered around vSphere 5 over the last couple of weeks and as I just published the last article I had prepared I figured it would make sense to post something similar. (Great job by the way Eric, I always enjoy reading your articles and watching your videos!) Although I did hit roughly 10.000 unique views on average per day the first week after the launch and still 7000 a day currently I have the feeling that many were focused on the licensing changes rather then all the new and exciting features that were coming up, but now that the dust has somewhat settled it makes sense to re-emphasize them. Over the last 6 months I have been working with vSphere 5 and explored these features, my focus for most of those 6 months was to complete the book but of course I wrote a large amount of articles along the way, many of which ended up in the book in some shape or form. This is the list of articles I published. If you feel there is anything that I left out that should have been covered let me know and I will try to dive in to it. I can’t make any promises though as with VMworld coming up my time is limited.

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.

vSphere 5 – Metro vMotion

Duncan Epping · Aug 3, 2011 ·

I received a question last week about higher latency thresholds for vMotion… A rumor was floating around that vMotion would support RTT latency up to 10 miliseconds instead of 5. (RTT=Round Trip Time) Well this is partially true. With vSphere 5.0 Enterprise Plus this is true. With any of the versions below Enterprise Plus the supported limit is 5 miliseconds RTT. Is there a technical reason for this?

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?