Disclaimer: The views expressed anywhere on this site are strictly mine and not the opinions and views of VMware, Inc.
So while recently working on a couple of vCloud design engagements I’ve been having some discussions around the recoverability of vCloud and its artifacts with some VMware colleagues and one in particular who I call Manchach (Michael Mannarino), the VMware architect that I mentioned on my previous posts related to Auto Deploy and Cisco UCS, but enough about him again, that dude is just crazy. So the talks were about finding ways to protecting and recovering the environment from the infrastructure and vApps components as much as we could in order to provide a solution that our customer could agreed to from a recoverrability standpoint. Now I want to make it clear that this is not the complete soup to nuts solution automatic recovery and it works with a specific use case at the moment, but I have some other pieces that I’m finalizing a couple of other efforts to streamline what we’re trying to accomplish here with the east administrative effort. This post is part one of a three part series. So Manchach (Michael Mannarino) pounded on my door the with a thorn in his side. The thorn was the recovery of vCloud Director. An age old problem with provisioning systems. Immediately we began to whiteboard solutions and prioritize the viability and complexity of each of the solutions. The goal was to create a recover solution for vCD within an environment based on full disaster recovery (names of environments are not important here – what is important is a viable recovery solution for vCD). The objective was to perform that recovery of workloads within vCD within an acceptable amount of the time, once a disaster has been declared on-site…Low and behold we believe we created a solution some 22 hours later…being a newlywed – you can bet I got no action at home that weekend working on the recovery…but ultimately for my sanity and my customers (present and future) it was worth it.
The environment for vCD recovery consisted of the following:
- ONE primary DC (let’s call it DCWest)
- ONE secondary DC (let’s call it DCEast)
- Close proximity to span the LAN networks between the primary DC and secondary DC.
- All workloads would run in production in the primary DC. All workloads would be recovered for production in the secondary DC
So it’s been a while since I’ve been able to post something in the clouds, I’ve been very busy and need to find the time to update and move PunchingClouds to a HOT new location, but I wanted to quickly put something out for those of you who used to or still come here from time to time. I recently ran into an issue with Auto Deploy, one of the new features of the vSphere 5 platform.
Auto Deploy seems to be picking up a great deal of interest out in the field and there have been a great deal of blog posts from Duncan Epping, (one half of the VMware Virtualization bad ass rock star! duo Frank and Duncan), Erick Sloof, Gabe’s Virtual World, and the rest of the community highlighting Auto Deploy’s configuration and capabilities. To be honest I think there is an obviously place in the market for Auto Deploy but there are a few things that need a bit work and fine tuning which I’m sure the folks at VMware will get to as they continue the push for cloud automation strategy. Overall Auto Deploy is a very nice and useful feature to have as long as there is a requirement in the infrastructure for it.
So recently while working on a plan and design of a brand spanking new vSphere 5 Architecture (Green Fields baby!!!!! how often do you get that?) I ran into an issue with Auto Deploy and the hardware that was to be used Cisco UCS. One of the key technical design decisions of this particular design was the implementation of stateless builds of ESXi 5 on Cisco UCS. The problem was not really a show stopper for us but we had to make sure the customer would approve the work around solution before we could proceed with it for production. This was more of matter of supportability from the customers perspective specifically than anything else.
So here is what happened and the discovery of the problem:
All of the Auto Deploy required components where deployed correctly in the required supported fashion (TFTP, DHCP, dedicated IP scope, etc), and just like a great majority of the companies in the world… most of their infrastructure services are based on Microsoft solutions (AD,DNS, DHCP, NAP, etc). So after configuring Auto Deploy and activating an initial boot image for the Cisco UCS blades, the blades were not able to PXE boot and connect to the Auto Deploy server (vCenter in this case), they were simply time out. After some research, troubleshooting and discussions with a colleague and lead architect on the project who I will refer to here as the Manchach we decided to take a different approach and try something new. The homeboy happened to be a very knowlegeable individual in the networking side of the house amongst many other things such as enterprise architectures, security, and other areas…enough of him. The whole point is that I listened and we decided to build a Linux based DHCP server and see what the outcome would be. We were able to identify that the Cisco UCS Blades were picking up their reserved IP address from the Linux based DHCP server but not the Microsoft DHCP server which effectively prove to be the reason for the Cisco UCS Blades failing to PXE boot and connect to the Auto Deploy server. Auto Deploy was key feature for the design of this architecture. I have experience in the past very few occasions where sometimes there are issues with Microsoft services interacting with other technologies that aren’t based on MS-DOS 6.22 : ) just kidding, but seriously we wanted to see if that behavior would repeat itself, and guess what… it didn’t. So here was the issue , the Cisco UCS Blades were not able to pick up and address from the Microsoft based DHCP service, but they were able to pick them up from the Linux based DHCP service (we used Ubuntu).
We proceeded with the creation of the new DHCP IP Scope and adding reservation for all hosts by mapping MAC addresses to IP’s and things worked fine with this approach. After some more research and digging we learned from Cisco that the issue was would be corrected in the new Cisco UCS version 2.0.
So here is the deal for those of you working with Cisco UCS version 1.4 be aware of this problem, if you’re considering the implementation of Auto Deploy for stateless builds and current DHCP solution is based on Microsoft DHCP service know that it won’t work unless you are using a Linux based DHCP solution or are on Cisco UCS version 2.0 (not confirmed by me yet). The work around is somewhat simple if the introduction of a Linux based DHCP server into the environment is possible.
We ended up upgrading the customer Cisco UCS 2.0 but have not been able to verify if the problem was rectified since the customer approved the deployment of the Linux based DHCP server in the management subnet.
I hope this is of use to someone. See you all on a black diamond near you!!!! More to come soon.
While working with a customer in a new VDI design and implementation a problem was brought to my attention in regards to some of the configuration items in View 4.5 in relation to Microsoft SQL Server 2008. The issue that was happening had to do with the configuration of the view events database. While trying to add the SQL Server 2008 database to in the View Admin Console the system kept generating the same error message, even thou all the information was accurate and the database was already available on the server. The error is displayed in the screenshot below:
View Events Database Error
The problem here has to do with authentication. In order to configure the View Events database correctly you have to use a SQL Server base account and not a Windows based account. This is a requirement for this to work. The environment on which this View implementation was being deployed was brand new and included new installations and instances of SQL Server 2008. All of the SQL Servers were configured for Windows based authentication only (single sign-on). The fix it’s somewhat simple as long as there aren’t any constraints that will prevent changing or updating the authentication method of the SQL Servers. The servers have to set to support both methods of authentication Windows, and SQL based. The screenshot below displays the location where to make the necessary changes on the SQL Servers.
SQL Server 2008 Authentication Settings
After making those changes and creating a SQL based account for that database the configuration of the View Events database succeeded without any issues.
Ever since I started to use the a MacBook Pro I have made an effort to use applications that work natively on the system without having to boot up VM’s in VMware Fusion in order to access tools and applications. Well it’s no news that there are plenty of great virtualization tools out there, but a majority of them cater to the Windows side of house. PerfMon doesn’t exist in OS X nor Linux operating systems. We do have an awesome tool developed by the folks at VMware called ESXPLOT. You may have heard of this tools already from crew whom I call the “Virtualization Blogging Consul” A.K.A the badasses of virtualization news such as Duncan Epping, Frank Denneman, Jason Boche, Scott Lowe, Eric Sloof, Simon Long, Scott Drumonds, and the rest of the top blogging folks community. As I finally got the tool working in my system and I wanted share a little step by step procedure since in a way I wasn’t really able to get it working right away, and maybe others would experience the same.
Installing ESXPLOT in OS X 10.6.5
First it’s important to understand a few facts about the software that comes pre-package with OS X in order to get this working right. OS X is pre-packaged with Python version 2.6. In order to get ESXPLOT woring right away you have to download and install the right version of another tool call wxpython. As listed in the instructions of the download site for the ESXPLOT tool, the big to point out here is that if you are going to stick with the Python version that comes with OS X which again it’s 2.6.1 you need to download the wxpython 2.8 for the python version 2.6 in order to get this going correctly. If you download a version of wxpython that doesn’t match the installed version of python in you system you’ll get an error message like the one listed below:
The Second thing to remember is that there are certain features on OS X that tend to have a 64bit architecture and load by default, and for this tool to work correctly you have to start this program (the esxplot.py script) in the 32bit environment, and this can be done in multiple ways. The screenshot below lists the option I used to get it working in my system:
After entering the settings, go to the /src directory where ESXPLOT was extrated and double click the esxplot.py file and as a result you should see something similar to the screenshot below:
I hope this post is of use, enjoy!
OK Folks, here it is… the vSphere Platform 4.1 upgrade has been released. The upgrade contains new features as well as improvements in scalability. Here is a list of a few things to be noted:
- Memory Compression
- DRS Host Affinity
- Storage I/O Control
- Network I/O Control
- Performance Reporting
- Cloud Scale
- ESXi Active Directory Integration
- Expanded HCL
For more details and definitions on the new improvements please got the VMware site and check out the what’s new documentation. Enjoy!
