July 29th, 2010 |
19 Comments
We were just talking about some random VMware acronyms during a lab day and I thought I would write the ones down which some of us didn’t know. (Even google did not have the answer to some) I guess the most difficult one to figure out was VPXA/VPXD, which refers to VPX which was the official name for vCenter back in the days….
ESX = Elastic Sky X
GSX = Ground Storm X also some times referred to as Ground Swell X
VPX = Virtual Provisioning X
VPXA = Virtual Provisioning X Agent
VPXD = Virtual Provisioning X Daemon
VMX = Virtual Machine eXecutable
AAM = Automated Availability Manager
VIX = Virtual Infrastructure eXtension
VIM = Virtual Infrastructure Management
DAS = Distributed Availability Service
Of course the big question is where the “X” comes from in ESX, GSX etc. To be honest I don’t know. Some say it comes from VMX and others say it was just made up by a marketing company. Update: According to Mike Di Petrillo in this interview (21:30) by Rodney Haywood explained that the X had been added by an Engineer to make it sounds technical! If any knows the true story let me know.
If there are any to VMware related acronyms that you feel should be on the list which are not too obvious… leave me a comment. (And too obvious would be something like vDS.)
July 28th, 2010 |
21 Comments
On an internal mailing list we had a very useful discussion around storage migrations when a SAN is replaced or a migration needs to take place to a different set of disks. Many customers face this at some point. The question usually is what is the best approach? SAN Replication or Storage vMotion… Both have its pros and cons I guess.
SAN Replication:
- Can utilize Array based copy mechanisms for fast replication (+)
- Per LUN migration, high level of concurrency (+)
- Old volumes still available (+)
- Need to resignature or mount the volume again (-)
- A resignature also means you will need to reregister the VM! (-)
- Downtime for the VM during the cut over (-)
Storage vMotion:
- No downtime for your VMs (+)
- Fast Storage vMotion when your Array supports VAAI (+)
- If your Array doesn’t support VAAI migrations can be slow (-)
- Induced cost if VAAI isn’t supported (-)
- Only intra Array not across arrays (-)
- No resignaturing or re-registering needed (+)
- Per VM migration (-)
- Limited concurrency (2 per host, 8 per vmfs volume) (-)
As you can see both have its pros and cons and it boils down to the following questions:
How much down time can you afford?
How much time do you have for the migration?
July 26th, 2010 |
6 Comments
Just got noted that the Presentation of the VCDX 3 Preperation Workshop has been published. This Powerpoint presentation was given by John Arrasjid and Pang Chen during Partner Exchange and got a lot of great feedback. For everyone aiming to become a VCDX over the course of the upcoming months this is definitely a must read!
VCDX Defense Preparation
Preparation time
- Plan on working a minimum of 30-40 hours to complete the application and supporting documentation.
Mandatory VDCX documentation
- Architectural design document with diagrams and blueprints
- Implementation and next steps documentation
- Validation/test plans
- Operational plan/guide
- Installation and configuration instructions
July 22nd, 2010 |
2 Comments
A week ago I already touched on this topic but I wanted to get a better understand for myself what could go wrong in these situations and how vSphere 4.1 solves this issue.
Pre-vSphere 4.1 an issue could arise when shares had been set custom on a virtual machine. When HA fails over a virtual machine it will power-on the virtual machine in the Root Resource Pool. However, the virtual machine’s shares were scaled for its appropriate place in the resource pool hierarchy, not for the Root Resource Pool. This could cause the virtual machine to receive either too many or too few resources relative to its entitlement.
A scenario where and when this can occur would be the following:
VM1 has a 1000 shares and Resource Pool A has 2000 shares. However Resource Pool A has 2 VMs and both will have 50% of those “2000″ shares.
When the host would fail both VM2 and VM3 will end up on the same level as VM1. However as a custom shares value of 10000 was specified on both VM2 and VM3 they will completely blow away VM1 in times of contention. This is depicted in the following diagram:
This situation would persist until the next invocation of DRS would re-parent the virtual machine to it’s original Resource Pool. To address this issue as of vSphere 4.1 DRS will flatten the virtual machine’s shares and limits before fail-over. This flattening process ensures that the VM will get the resources it would have received if it would have been failed over to the correct Resource Pool. This scenario is depicted in the following diagram. Note that both VM2 and VM3 are placed under the Root Resource Pool with a shares value of 1000.
Of course when DRS is invoked both VM2 and VM3 will be re-parented under Resource Pool A and will receive the amount of shares they had originally assigned again. I hope this makes it a bit more clear what this “flattened shares” mechanism actually does.
July 22nd, 2010 |
1 Comment
I received multiple questions around this so decided to ask around internally. I managed to get ahold of the VMware Update Manager (aka VUM) Product Manager and after exchanging a couple of emails this is the outcome:
VMware vSphere Compatibility Matrixes
Table 13 on page 14 of the above linked document states that VUM doesn’t support MS SQL 2008 Standard. This is however untrue and should be considered as a document bug. It is supported and the document will be modified soon to reflect these changes.
July 21st, 2010 |
7 Comments
When installing vCenter 4.1 on Windows 2008 R2 64-bit one of my colleagues ran into the following error message:
This product can only be installed on the following 64-bit operating systems:
Windows XP SP2 or above
Windows 2003
Windows 2008
Although this message is actually correct it was not what was causing this problem as he followed the documentation and installed Windows 2008 64-bit. In this case Active Directory had been installed and that was the reason it was failing. As vCenter installs ADAM it can’t run on top of a server which hosts AD.
July 20th, 2010 |
1 Comment
As many of you already know there is an issue with the encryption mechanism of ESX(i) 4.1. When passwords are used which are longer than 8 characters the password will be truncated after the 8th character. As such during authentication only the first 8 characters are used. In other words if you have a 10 character password you will only need to type the first 8 characters correct and the rest can be completely random.
The KB article that was published yesterday contains a workaround to change this behaviour. I recommend everyone to read the article and implement this workaround when your password policy describes passwords longer than 8 characters.
vSphere 4.0 Quick Start Guide