I just noticed that the Horizon documentation is offered in epub and mobi format. I have been told that this is the first of many more docs to be released in this more universal format. I am happy that VMware decided to adopt this format. It does lead to another question though. I am part of tech marketing and we produce a lot of collateral. Some documents are fairly lengthy and I always have the feeling that many people won’t read docs which are more than 50 pages. Is this any different with epub/mobi? Would you say that these formats enhance readability? If not, what would be a good way of offering documents of between 50 – 150 pages?
Server
Win a signed copy of “Cloud Computing with VMware vCloud Director”
Book #24, As you hopefully know about a month ago my latest publication was released titled “Cloud Computing with VMware vCloud Director“. When I was visiting Palo Alto a week ago I met up with one of the co-authors and vCloud Security Expert Michael Haines. Michael managed to get a stack of books signed by the author of the foreword, Paul Maritz. Luckily he managed to get 3 of my books signed by Paul Maritz as well. Of course I will hold on to one of those copies myself, but I want to offer all of you the opportunity to win a signed copy by Paul Maritz.
So if you want to win a copy, comment on this post and let me know what cloud computing means to you… that is all you need to do. I will contact 2 randomly picked winners on the 8th of June and announce their names in this article.
Randomly picked winners (thanks to my daughter for assisting me in randomly picking :-)): Adam, Mark
Ephemeral ports?
A couple of days ago one of my colleagues released an article about Ephemeral Ports. The article explains about how Ephemeral ports could be used as a “backup” when vCenter is down. The summary of the article is in my opinion the paragraph I quoted below.
If the inability to quickly provision a new VM or to reconnect a vNIC while vCenter Server is unavailable has kept you from considering a pure vDS network architecture, ephemeral port groups may be a suitable safety net. You would not even need to use ephemeral port groups for production virtual networks — simply create a few to have as backups for accessing the most critical VLANs.
This started a discussion internally as the default setting is not Ephemeral but Static. So the question that this resulted in was should we define a new standard or are the “Static” port binding just as good as Ephemeral? I believe that many people are hesitant of using a pure vDS infrastructure due to the inability to make changes to the vDS when vCenter would be unavailable. This applies to both ephemeral and static however and actually leads to another point, which we won’t discuss now, vCenter resiliency. Now, from a virtual machine perspective even if vCenter is down, and Static is used as the port bindings, the virtual machine can be powered on and off. With Static all ports are pre-defined on the host level and when a virtual machine is assigned a port it can consume it. Now the difference between Ephemeral and Static is that Ephemeral allows you to assign “new ports” to new virtual nics or virtual machines. I guess the question is how often do you make changes to the network of your virtual machines when vCenter is down and what type of changes?
Seriously, do we really want to make substantial changes to our environment when our management platform is not available? I believe we shouldn’t and I also feel that Static portgroups are the way forward, they have more or less the same level of flexibility Ephemeral have and on top of that Static offers a lot of advantages from a scaling perspective!
das.failuredetection time and relationship with isolation response
I had this question coincidentally two times of the last 3 weeks and I figured that it couldn’t hurt explaining it here as well. The question on the VMTN community was as follows:
on 13 sec: a host which hears from none of the partners will ping the isolation address
on 14 sec: if no reply from isolation address it will trigger the isolation response
on 15 sec: the host will be declared dead from the remaining hosts, this will be confirmed by pinging the missing host
on 16 sec: restarts of the VMs will beginMy first question is: Do all these timings come from the das.failuredetectiontime? That is, if das.failuredetectiontime is set to e.g. 30000 (30 sec) then on the 28th second a potential isolated host will try to ping the isolation address and do the Isolation Response action at 29 second?
Or is the Isolation Response timings hardcoded and always happens at 13 sec?
My second question, if the answer is Yes on above, why is the recommendation to increase das.failuredetectiontime to 20000 if having multiple Isolation Response addresses? If the above is correct then this would make to potential isolated host to test its isolation addresses at 18th second and the restart of the VMs will begin at 21 second, but what would be the gain from this really?
To which my answer was very short fortunately:
Yes, the relationship between these timings is das.failuredetectiontime.
Increasing the das.failuredetectiontime is usually recommended when an additional das.isolationaddress is specified. the reason for this is that the “ping” and the “result of the ping” needs time and by added 5 seconds to the failure detection time you allow for this test to complete correctly. After which the isolation response could be triggered.
After having a discussion on VMTN about this and giving it some thought and bouncing my thoughts with the engineers I came to the conclusion that the recommendation to increase das.failuredetectiontime with 5 seconds when multiple isolation addresses are specified is incorrect. The sequence is always as follows regardless of the value of das.failuredetectiontime:
- The ping will always occur at “das.failuredetectiontime -2”
- The isolation response is always triggered at “das.failuredetectiontime -1”
- The fail-over is always initiated at “das.failuredetectiontime +1”
The timeline in this article explains the process well.
Now, this recommendation to increase das.failuredetectiontime was probably made in times where many customers were experiencing network issues. Increasing the time decreases the chances of running in to an issue where VMs are powered down due to a network outage. Sorry about all the confusion and unclear recommendations.
New Whitepaper: VMware ESXi 4.1 Operations Guide
As part of my new role within VMware Technical Marketing I am responsible for creating collateral. Most of you have seen the series of articles about the operational differences between ESX and ESXi. After finalizing the series I transformed them into a whitepaper. I guess one thing that stood out for me while going through that process is that writing a whitepaper is substantially different than writing a blog article and even a book. I am not sure how to explain it, but a whitepaper feels less personal and more official and requires a different writing style. On top of that there are of course multiple reviews, style edits and much more. But anyway, that is not the point of this article… I just wanted to let you know that it is out there, and I hope you will enjoy reading it.
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.
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.
We are also working on automating some parts of the upgrade, and I hope to be able to publish an update on that soon.