In case you have been living under a rock and haven’t heard, VMware is getting ready to release a new set of advanced certification exams that will take you along the path to become a VMware Certified Design Expert on vSphere 4 (VCDX4). Just like VCDX3, it starts with the requirement of being a VMware Certified Professional on vSphere 4 (VCP). You will then need to pass two exams before being able to submit and defend your design. VMware has decided to award new certification statuses for passing these exams. The exam to become a VMware Certified Advanced Professional on vSphere 4 – Datacenter Administration (VCAP-DCA) is currently finishing up its beta run. The exam to become a VMware Certified Advanced Professional on vSphere 4 – Datacenter Design (VCAP-DCD) is not yet in beta. The path to achieve VCDX4 status is laid out on VMware’s site and is illustrated below:
Just like Jason Boche, William Lam and Duncan Epping, I had the privilege of taking the beta version exam. As you can see from the upgrade path, I am not required to take the exam to obtain the VCDX4, but I am a glutton for punishment I guess. Also, not having it as a requirement took some of the pre-test jitters off of me. At first, scheduling conflicts prevented me from being able to sit for the exam within VMware’s original deadline. However, I got a call on June 17th that I could take it on July 2nd. Wow…a two week notice, and on my only scheduled day off since April. But I eagerly accepted the invite. Because of the limited notice and the fact that I was juggling a few projects at the same time I debated even studying for the exam. An unscientific survey on twitter showed that 4 out of 4 followers recommended that I study for the exam. I don’t want to come across as arrogant or as a “know-it-all.” My argument here is that I am already a VCDX, I should know this stuff. My schedule and my severe procrastination tendencies made me decide to do a little bit of review the night before.
Before I begin with my thoughts on the exam content, I want to express that I only had two “issues” with the exam experience itself. First a little bit of background: The exam consists of 41 “questions”, which are actually multifaceted problems that you need to solve with the tools that are presented to you. You have 4.5 hours to complete the exam. The problems are presented in a familiar Vue test engine. You click a button to switch to a desktop session with a few of the typical tools used to administer a vSphere environment. The issue was with the screen refresh for the GUI based tools. When I clicked on an item, sometimes all of the tabs are not presented properly or the content is not complete. This was pretty annoying and sometimes a hindrance. When I participated in the beta exam for the VI3 Advanced Administration Exam, I did not experience this. Hopefully, this will be cleared up before the exam becomes GA. I would think that a leader in desktop virtualization would have a method to avoid this type of thing. The second issue is a provision for breaks. You can take “unscheduled breaks” but I think the clock keeps ticking. It would be nice to actually have a scheduled break without a time penalty. As you get older, you NEED the breaks…
Now, on to the content. Forget about me actually telling you the actual content of the exam. The NDA prevents this and I want to participate in future beta exams. I got my VCDX3 via beta exams and I hope to get my VCDX4 this way!
I’ll admit it. Working primarily in the SMB market limits your skills a bit. I am not as exposed to some of the more advanced features of vSphere 4 as I used to be when I worked in an “enterprise” market. I skipped a couple of problems because of this. I intended to return to them, but the clock ran out before I could. The problems were a very good compendium of the advanced skills required of a more senior VMware Administrator. It was the toughest exam that I have ever taken. The second toughest was the VI3 Advanced Administration Exam. I thought the questions were very fair and there was nothing in the content that caused me any objections.
I was pretty relaxed when I started the exam, but started to PANIC during the last 30 minutes.
The one (personal) issue I have with this type of exam is that it measures you at a point in time on how much you have memorized. Since I don’t want to use an example of a problem that may be on a VMware exam, I will use one of my cars as an example here. Say, for instance that I am sitting in on the 1972 Ford Gran Torino Advanced Administration Exam…
Let’s say a question on the exam is to set the Ignition Points gap. This is something I did a few times on several cars. I know where to find the ignition points. I know how to set the gap. I have the proper tools to do it. But I don’t know what that setting should be. In the REAL world, I would look it up in a manual or on Google. And I looked up the setting every time I did it. Would I fail the test because I know HOW to do it, but don’t know the proper setting? Probably. My teenie brain can’t hold all of this information – especially with all of the Monty Python references in there, not to mention the words for almost every song by Rush and Iron Maiden…
Back on track… Echoing Duncan, Jason and William, I have a few tips to offer for this exam:
- Read the Exam Blueprint. Perform each task listed in the blueprint a few times, so you know HOW to do it. You DO have access to “–help” and man pages during the exam if you are stumped. However, refer to item #3.
- Build a LAB! You will need it for item #1. You don’t have to go out and buy servers and storage. All you need is a reasonably fast 64bit PC or laptop with a decent amount of RAM. Some things may be slow, but you will get through it. You can make an ESX server in a VM. Use VMware Player or VMware Workstation to host your lab VMs. Every VMware product in the blueprint is either free or has an evaluation period. Didn’t you get a free VMware Workstation license with your VCP?
- Manage your time! I ran out of it. You have the opportunity to go back. Skip questions if you don’t know how to do it or think it will take a while. The other thing I noticed was that, since the exam is using a live lab environment, the tasks happen in real time. During my panic state, I started to multitask and work on more than one problem at a time. Instead of clicking “Next” and waiting for the task to complete, click “Next” and start on the next problem. Juggle two or three problems. Use your dry erase board to keep track of skipped problems and multitasking. I am not very fast with my typing and I am constantly mixing up letters in words. I call it “typing dyslexia” and it doesn’t help me in these situations!
I don’t know if I passed this one. I am a little bit pessimistic at this time. I will find out in “4-6 weeks”, but that is VMware Time… Good luck to all that have or are planning to take this exam.
OK..I’ll admit it: I am spoiled by the capabilities of vSphere. What other platform lets you schedule system updates that will occur unattended and without outages of the applications being used? I don’t mean the winders patches, they require a monthly reboot. I am talking about the hypervisor updates. VMware Update Manager coordinates all of this for you. Then along comes vShield Zones to break it all.
First, let me explain what I am trying to do. To simplify things, vShield Zones is a firewall for vSphere Virtual Machines. Rather than regurgitate how it works, take a look at Rodney’s excellent post. A customer has decided to use vShield Zones to help with PCI Compliance. The desire is that only certain VMs will be allowed to communicate with certain other VMs using specific network ports, and to audit that traffic. ’nuff said.
vShield Zones seems to be the perfect solution for this. It works almost seamlessly with vCenter and the underlying ESXi hosts. It provides hardened Linux Virtual Appliances (vShield Agents) to provide the firewalling. It provides a fairly nice management interface to create the firewall rules and distribute them to the vShield Agents. Best of all, IT’S FREE! At least for vSphere Advanced versions and above. Keep in mind, that this is still considered a 1.x release and some things need to be worked out.
Now, on to the gotchas.
Gotcha #1 – Networking
When it comes to networking, the vShield Agent is designed to sit between a vSwitch that is externally connected via physical NICs (pNICs) and a vSwitch that is isolated from the outside world. The vShield Agent installation wizard will prompt you to select a vSwitch to protect. This is illustrated below. The red line indicates network traffic flow.
Click the Image to Enlarge
This works like a champ in this configuration, using a vSwitch for management, which is naturally on an isolated network to begin with, using a vSwitch for VMs to connect to the vShield Agent and using a vSwitch to connect everything to the outside world. This can also be deployed with limited down time. If you are lucky enough to have the Enterprise Plus version, you may want to use a vNetwork Distributed Switch or even a Cisco 1000v. You will need to make some manual configurations to make this work as outlined in the admin guide.
The gotcha is with blade servers or “pizza box” servers that have limited I/O slots. If all of the VM traffic must flow through the same physical NICs and you use a vSwitch, then you need the vShield Agent to protect a port group rather than an entire vSwitch. You will need to create a vSwitch with a protected port group and connect it to the pNICs. Then you you can install the vShield Agent. Once the vShield Agent is installed, you will need to go back to the vSwitch attached to the pNICs and add an unprotected port group. This is illustrated below. The red line is the protected traffic and the blue line is the unprotected traffic.
Click on Image to Enlarge
As you can see, there is an unprotected Port Group (ORIGINAL Network). This needs to be added to the vSwitch AFTER the vShield Agent is installed. If the ORIGINAL Network is already a part of the vSwitch, it will need to be removed BEFORE installing the vShield Agent. In order to avoid an outage, you will need to disable DRS and manually vMotion all VMs off of the ESX/ESXi host before installing the vShield Agent and modifying the port groups.
Gotcha #2 – DRS/HA Settings
The vShield Agents attach to isolated vSwitches with no pNIC connection. As you should already know, using DRS and vMotion on an isolated vSwitch could cause inter-connectivity between VMs to fail. By default, you cannot vMotion a VM that is attached to an isolated vSwitch. You will need to enable this by editing the vpxd.cfg file. You will also need to disable HA and DRS for the vShield Agents so they stay on the hosts where they are installed. Both are well documented. Obviously, you will need to install a vShield Agent on every ESX/ESXi host in the cluster.
The Gotcha here is that, with HA disabled for the vShield Agent, there is no facility for automatic startup. There is an automatic startup setting in the startup/shutdown section of the configuration settings. First, this is an all-or-nothing setting. Second, according to the Availability Guide:
“NOTE The Virtual Machine Startup and Shutdown (automatic startup) feature is disabled for all virtual machines residing on hosts that are in (or moved into) a VMware HA cluster. VMware recommends that you do not manually re-enable this setting for any of the virtual machines. Doing so could interfere with the actions of cluster features such as VMware HA or Fault Tolerance.”
So, if a host fails, HA will restart all protected VMs on different hosts. If the host comes back on line, you risk having DRS migrate protected VMs back to that host. This will cause those VMs to become disconnected because the vShield Agent will not automatically start. If a host fails, hope that it fails good enough so it won’t restart.
Gotcha #3 – Maintenance Mode
At the beginning of this post, I mentioned how VMware Update Manager has spoiled me. VUM can be scheduled to patch VMs and hosts. When host patching is scheduled, VUM will place one host in Maintenance Mode, which will evacuate all VMs. Then, it will apply whatever patches are scheduled to be applied, reboot and then exit Maintenance Mode. It will repeat this for each host in a cluster. This works great unless there are running VMs that have DRS disabled, like the vShield Agent.
In the test environment, when a host was manually set to enter Maintenance Mode, it would stall at 2% without moving the test VMs. I am not sure the order that VMs are migrated off, but none were migrated in the test environment. This could vary in different installations. Here’s the gotcha: you cannot power the vShield Agent off because the protected VMs would become disconnected. You cannot migrate it to a different host because it would cause a serious conflict and cause protected VMs to become disconnected. The only thing you can do is place the host in Maintenance Mode, then MANUALLY (*GASP*) migrate all of the protected VMs and then power the vShield Agent off. So much for automated patch management. We’re back to the “oughts.”
I said already that vShield Zones is a 1.x product. It’s a great firewall, but it has a few gotchas that you need to consider. The benefits may outweigh the negatives. But vSphere is a 4.0 product.Some of this should be able to be addressed by tweaking vCenter or host settings.
vShield Zones should be smart enough to allow us to select specific port groups to protect rather than an entire vSwitch. I guess whatever scripting is being done in the background will need to be changed for this. Maybe we need a Ghetto vShield?
One of the REALLY smart people at VMware should be able to tell us the “order of migration” when a host is placed in Maintenance Mode. Once that is determined, there is probably a configuration file somewhere that we could tweak to change it.
There should be a way to set up automatic startup and shutdown of individual VMs. The Startup/Shutdown settings sort of deprecated once DRS was introduced. The only time it is useful is with a stand-alone server or in a NON-DRS cluster. I guess the only thing that could be done is to add a script somewhere in rc.d or rc.local to start up these VMs, but how can that be done in a “supported” fashion with ESXi and is it supported in either ESX or ESXi?
I brought these issues up with some VMware engineers and they assure me that they are working on this. Hopefully they will figure it out soon. I hate doing things manually. It seems like it is anti-cloud.