Today I was working on a couple of test scenarios in a remote lab. For some reason the latency was a lot higher than normal and I was very difficult to type anything in the Remote Console through the vCenter Client. Every single character I tried popped up 2 or 3 times… which makes it very difficult to type a password as you can imagine. I knew I read a KB article about this exact problem a long time ago. Considering it is KB 196 I probably wasn’t the first to bump in to this. The solution is fairly simple:

• Power off the VM
• Edit Settings
• Click the Options Tab
• Click “General”
• Click “Configuration Parameters”
• Click “Add Row”
• Enter the name: keyboard.typematicMinDelay
• Enter the value: 2000000

Although the KB article doesn’t mention it, this also applies to vSphere 5.0.

I had the question today what happens to a powered off VM when the host they are registered against fails? This customer always has multiple powered off VMs and was afraid their VMs would show up as orphaned. I was pretty confident that the VM would be re-registered against one of the remaining hosts in the cluster, but I validated it just in case and this is what the events section of the VM shows:

Relocating from cs-tkmt-h08, emc-vnx-fcoe to cs-tkmt-h05, emc-vnx-fcoe

In other words, the VM is relocated from my ESXi host cs-tkmt-h08 to cs-tkmt-h05. No need to worry about orphaned VMs and manually registering them against the remaining hosts… vSphere does it for you.

I started diving in to vShield App and one thing that I like about vShield App is that it allows you to use different types of objects to apply your policies to. Never really put too much thought in to it, but considering the world is more and more changing to policy based management this fits right in. I just wanted to share something that I was working on, any feedback / thoughts are welcome…

The VMware Cloud Infrastructure aims to reduce operational overhead and lower Total Cost of Ownership (TCO) by simplifying management tasks and abstracting complex processes. The focus of this architecture, as indicated by our customer requirements, is resource aggregation and isolation through the use of pools for each of the crucial pillars: network, storage and compute. Each of the three pillars will be carved in to multiple units of consumption with priority allocated based on their service level agreement. This will be achieved by leveraging core functionality offered by vSphere 5.0. Subsequently vShield App will be used to isolate each of the different type of workloads. As a hypervisor-based application-aware firewall solution, vShield App allows defining policies to logical, dynamic application boundaries (security groups) instead of physical boundaries.

This resource and security layering method will allow for a fast and safe deployment of new workloads.

Each of the different types of resources are carved up in to different groups for each of the respective workload types. A virtual machine, or vApp, will be deployed in one of the three different compute and security groups after which a specific networking group will be selected and a storage tier. Compute, Security and Network  group types are currently defined based on the different type of workloads this virtual infrastructure will host. In the future additional blocks may be added based on the requirements of the internal customers and the different types of workloads being deployed…

Mike Laverick started a campaign last week on the VMware Community Forums and asked for the VMTN Subscription to be reinstated, coincidentally the same request came in through the VMUG board. For those who have never heard of the VMTN Subscription program it was similar to MSDN and enabled you to run VMware software in your lab environment for a fixed yearly fee. Ever since the program was cancelled every now and then people asked for it to be reinstated. This time it is different, it is not a few people who are backing the request but so far the community thread has over 10 pages worth of comments and there are literally multiple new blog posts about this topic every day.

During the weekend I dropped my management an email about this campaign and all the traction it had within the community. Literally within minutes I had a reply. I am happy to be able to confirm that we are investigating the option to reinstate the VMTN Subscription program. Keep in mind that starting a program like this does take time and the program will need a serious overhaul. As such I cannot make any promises on when this will happen. I do want to stress that all feedback is highly appreciated, we are listening! All blog posts voicing your opinion on why this should happen are more then welcome and all comments on the VMTN thread will be read by our team.

Head over to the community thread and post your feedback:

http://communities.vmware.com/thread/335123

My colleague Cormac posted an article about this already, but I figured it was important enough to rehash some of content. As many of you have experienced there was an issue with ESXi 5.0 in iSCSI environments. Booting would take a fair amount of time due to the increase of the amount of retries in the case creating a connection to the array would fail.

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.

I was just browsing through our documentation and stumbled on something which has got some cool potential.

http://pubs.vmware.com/vsphere-50/index.jsp?topic=/com.vmware.vsphere.storage.doc_50/GUID-F78EB579-B11C-4E65-9EE3-145888A005F6.html

This describes how to setup the vSphere side of things for a mirrored disk within a Windows 2008 Guest. Just imagine doing in-guest mirroring of your data while doing FT on the outside. This means you would be able to span multiple sites without the need for a replication mechanism.

I asked around and unfortunately this scenario is not supported today for vSphere FT, but it definitely has potential… Another way to solve this problem would be if we could somehow leverage the Mirror Mode driver that is used by Storage vMotion today. Once again, this is not available today and I don’t even know if people are working on it… just something that popped up and something that has great potential and seems like a small step.

I wrote an article about the scenario where all host fail, due to for instance a power outage, and how HA responds to it. I had a question today if this was still valid with vSphere 5.0. I figured it wouldn’t hurt to describe the steps that vSphere 5.0 takes.

1. Power Outage, all hosts down
2. Power on hosts
3. Election process will be kicked off. Master will be elected.
4. Master reads protected list
5. Master initiates restarts for those VMs which were listed as protected but not running

Now the one thing I want to point out is that with vSphere 5.0 we will also track if the VM was cleanly powered off, as in initiated by the admin, or powered-off due to a failure/isolation. In the case they are cleanly powered off they will not be restarted, but in this scenario of course they are not cleanly powered off and as such the VMs will be powered on. The great thing about vSphere 5.0 is that you no longer need to know which hosts where your primary nodes so you can power these on first to ensure quick recovery… No, you can power on any host and HA will sort it out for you.