I was recently given the opportunity to review Packt Publishing’s recent release of Implementing VMware vCenter Server: A practical guide for deploying and using VMware vCenter, suitable for IT professionals. At first glance, I wondered how an entire book could be written about vCenter alone. While reading it, though, I was pleasantly surprised time and again when I saw how much good information was shared. This book is an excellent primer for those new to vCenter and really, VMware in general.
In response to Miguel’s post, here are my thoughts:
I’m sure at least one of the VMware dudes Miguel was talking to was once a Windows System Administrator. I’m also sure that that same VMware dude cringed at the thought of needlessly putting multiple services on a single VM. He probably thought that as long as the customer had enough money for Windows Server licenses, compute and disk resources, that one should obviously separate each service into their own server. Now, to take a step back, let us say that, yes, it certainly is possible to put all the services you mentioned, vCenter, SQL 2008, VUM, and maybe even SRM on the same box, whether virtual or physical. But of course, whether this is possible or not is not in question. It’s whether it should or should not be done in the first place. I’m going to pull out the age old consultant’s answer and say, “It depends.”
It depends on if the customer has the budget for more Windows or SQL licenses. Does the customer have the compute and disk resources for several more servers? Is there already an existing SQL box or cluster that could be used? Is a DBA on staff, or at least a competent Windows Server admin? Does the customer’s environment even need a full blown SQL installation or would SQL Express do fine?
Now I’m coming from a background of government contracting where money is usually thrown at such projects. Resources for such an implementation are little thought about because they’re going to be there no matter what. This question could impact SMBs more, but probably not large corporations.
I think there are certainly right and wrong ways to implement based on circumstances. On the one hand, if you have the licenses, compute, disk, and administrative resources, I say absolutely, put each service on it’s own separate box. In more constrained environments, you may need to double up two or more services.
That’s not the least of it. Recovering from a failed VM will cost you less in time, effort, and hopefully, money. With an “all your eggs in one basket” approach, if one VM goes down, is somehow unrecoverable, then you’ve lost a lot of data. Separating your services reduces the liklihood that any one VM failure/loss will result in mutlitple services lost.
So I was having a discussion with a few fellow VMware dudes, and we were discussing the vCenter installation methods. One train of thought is to install vCenter, VUM, SQL 2008,, and SRM on 1 VM with 2 vCPUs, 4 GB of memory an a 100 GB drive, Monitor for performance and adjust as required by analyzing the performance data. I have alwbeen doing installations this way lately without issue. I have also done installations on dedicated SQL boxes \ VMs. I have gotten good performance out of the environment with having all services on a single VM. In larger environments of 20 or more hosts and 300 + VMs, I have used a dedicated SQL server. The SRM documetation recommends a separate server for the SRM installation, but I have not seen any issues with it on the same box, and there was not any performance degradation in an…
View original post 147 more words
This is a quickie post to share what I found when installing vCenter Server on a 64-bit Windows Server 2008 Enterprise Edition virtual machine. This VMware KB article is the error we received.
Apparently, during the installation of vCenter Server, Active Directory Lightweight Directory Services is installed. I hadn’t noticed this before. We had no server roles installed prior to installing vCenter, but after clicking through the error boxes that appeared, we saw that AD LDS, sure enough, appeared to be installed.
Towards the end of a customer’s virtualization implementation we’re doing some clean-up of the environment. During the initial setup I was using my own local email address to test various alerting processes, of which there are several. For instance, every SQL Server maintenance task sends a success/failure e-mail alert, the NetApp Virtual Storage Console plug-in can be configured to e-mail an administrator after snapshots are taken, and the Dell iDRAC can send e-mails on hardware status changes. All those are fairly quick to configure or lack a way to script a quick solution. But with 40 default alarms in vSphere, three vCenters, and being lazy as I am, I knew there must be a better solution than right clicking 120 alarms and copying-and-pasting an email address. As the proverb goes, if you repeat it, script it. So I set out to find how PowerCLI could help me.
This post is the third in a series dedicated to helping you set up your update infrastructure in vSphere 4.1. Part I is about installing and configuring Update Manager. Part II shows you how to install and configure the Update Manager Download Service. As the last in this series, this post will explain how to patch your ESX/ESXi hosts.
This walkthrough is part II of a series of guides on installing and configuring VMware’s tools for updating and patching ESXi 4.1 hosts. You can find Part I here and Part III here. The Update Manager Download Service (UMDS) is used in an air-gap environment where the vCenter Update Manager server (VUM) does not have access to the Internet to download patches itself – instead it relies on UMDS to download the patches. Once patches are downloaded, they’re manually copied via removable media, usually a CD/DVD, to VUM. Once VUM has the patches, it then works through the vSphere Client and the Update Manager plug-in to update the hosts. Although VUM can download operating system patches for Windows and metadata for Linux patches, we’re not using this configuration in this guide. We’re assuming the environments are updated via WSUS or SCCM.
So during my first data center virtualization project, I had to write up a series of documents for internal reference. These documents were to help us perform a standard installation at each site we migrate. I thought it would be helpful to post them for anyone else looking to perform these tasks, as well. This series of posts is about VMware Update Manager 4.1U1 and its associated Update Manager Download Service. It appears in three posts because the topic can be logically separated into three steps: installing and configuring VUM, installing and configuring UMDS, and a patching guide once your initial update infrastructure is in place. This post, as you can see, is part I. Let me know if it helps you out or if I missed something. All the best!
At a minimum, you’ll want to perform regular backups of your vCenter, Update Manager, and System databases. You don’t have to be a DBA to perform simple backups. You don’t need to know T-SQL or database programming to perform these steps. There’s an easy wizard that walks you through a standard Windows Next-Next-Finish set up.
There are a couple things to note in the walkthrough below. We’re using SQL Server 2008 Enterprise Edition 64-bit on a 64-bit Windows Server 2008 SP2 Enterprise Edition. The SQL server is also a virtual machine in a vSphere 4.1 environment.
Hopefully you’ll never have a disaster hit your datacenter, but if you do, this guide can show you how to restore your vCenter database to your latest backup. Your vCenter database holds all the information you see in the vSphere Client and more. Although your VMs will still run your ESXi hosts without vCenter and its associated database, you lose a lot of enterprise functionality.
In my testing, I found the SQL server to which you recover can have a different name. I did not change the name of my vCenter server. All machines involved had different IP addresses and resided in a different domain. All domain service accounts were recreated in the test domain. I’m leaning towards the possibility that the vCenter server can have a different name, as well.