Below are the notes I have taken during the NJ/NY VCDX workshop at @iamAntonZ ‘s place. We had a great opportunity to have 2 VCDX panelists giving the VCDX workshop, Niran Even-Chen ( ) and Agustin Malanco (@agmalanco). You could find more info on this at http://nycvmug.blogspot.com/2016/06/re-cap-of-njnyv-vcdx-workshop.html
These notes are by no means to be used or relied on as primary source for your VCDX preparation.
Your design must include all the VCDX blueprint points.
Don’t use any kind of blogs as an official source for your references . Official VMWARE docs are the only sources that you can quote or reference to in your VCDX design.
One of the main changes to VCDX is removal of the “Troubleshooting” scenarios from the defense.
One design can be submitted 2 more times, if it did not get accepted the 1st time around. This means that you will need to make some modifications to your design, before resubmitting it again. You won’t get any detailed information on why it failed the submission, but you might get a generic response such as ” Storage or Networking needs more info”.
Same design could potentially be submitted by 3 different people, and they must submit it at the same time for the same VCDX track. Also, each and every applicant must know the design inside out, not just the portion he or she design.
It takes an average of 4-7 month to prepare the design and validate it. Once you got accepted for defense, get yourself an official VCDX mentor. The mentor will not be fixing your design for you, but rather guide you and advise you on proper documentation. Lookup the directory, and work with him to help you out on this. Just keep in mind that they are ( VCDX mentors) are not being paid for it and do it rather on their own time.
Continue reading “VCDX workshop notes”
I had an interesting case a while ago. One of our test ESXI hosts running ESXi version 5.5 has crashed taking down number of test environments with it.
All the attempts to bring the host back to life was in vain, as each reboot was giving us a Purple screen of Death. We needed these test environments up and running ASAP, and due to time limit on hands, it was decided to :
- keep the current VMFS datastore and install partition intact,
- Install ESXI 5.5 from scratch onto a USB flash drive, and
- Re-create the vSwitches
- Re-import the VMs into inventory
- Re-import and start up the vCenter
- Login to vCenter and bring up the test environment back online
Luckily this test server- a Cisco UCS C220- had its CIMC enabled, and IP configured for remote access. So, I was able to connect to the hosts’s remote management panel (CIMC) and install the new Esxi via Continue reading “Recovering VMs after a vmware’s Purple Screen of Death (PSOD)”
These are the esxi host log files one needs to be quite familiar with. These logs should be checked depending on the issue you facing, and trying to troubleshoot.
- /var/log/auth.log: ESXi Shell authentication success and failure.
- /var/log/lacp.log: Link Aggregation Control Protocol logs.
- /var/log/hostd.log: Host management service logs, including virtual machine and host Task and Events, communication with the vSphere Client and vCenter Server vpxa agent, and SDK connections. Continue reading “Some useful UNIX shell commands for VMware admins”
I have not seen any special feature improvements in 5.5 over 5.1 that would have benefited our environment, and as with any other major new releases was patiently waiting for VMware to come out with Update 1 for vSphere 6. Originally I had the SSO, VMware Update Manager, and vCenter each running on its own server. Databases for SSO and vCenter are separated to a standalone SQL 2008 R2 server. I ended up combining the VUM and vCenter on one single server, and upgrading the SSO to PSC (Platform Services Controller) and kept it separate, in case if we go with 2nd vCenter in the future.
Upgrading vCenter from 5.1.x to 6.0 is quite straight forward process, mount the vCenter 6 VMware-VIMSetup iso image to the vCenter server, and run the installer. It will recognize that there is a previous version installed and offer you to upgrade it.But first, make a backup of working production servers, before the upgrade. Shutdown the VMs, and copy the SSO and vCenter vmdks to a separate folder – in case if snapshots decide to take a break from work. Take the SSO, vCenter snapshots, and of course backup the SQL databases, if you have them running separately.
Don’t despair, if you receive the below error during vCenter upgrade: Continue reading “Error while upgrading from VMware vCenter 5.1 to vCenter 6.0”