VM /ETC

Archive for the ‘VirtualCenter’ Category

This post explains functionality of Veeam Backup and Replication (BaR) that you are not going to see in the User Guide. I was browsing the Veeam Forums and came across this thread – Backing up Veeam / vCentre Physical Machine which inspired me to write this post. The thread is actually about having an with an issue using with the scheduled backup of a physical vCenter server, which also happens to be running Veeam Backup and Replication, using another product.

I’ll get right to it. You can make a backup copy of physical SQL databases with Veeam BaR. Both vCenter and Veeam BaR have a SQL backend. You can’t schedule this as a job, but there are several scenarios where you could take advantage of a quick and easy, one time, manual backup  – before an upgrade or patch, for example.

Although I work for Veeam, this is not necessarily an intended or fully supported usage of the product. This is an easy alternative for the VMware admin to CYA , however.

I’ll start with a brief introduction on how the SQL U-AIR wizard is supposed to work, and then I will explain how you can use an admin switch to make a backup copy of SQL database whether on a VM or a physical server. VMware vCenter and Veeam BaR/Monitor/Reporter all have SQL back ends. 

The U-AIR Up There

To do this you can use the SQL U-AIR wizard. U-AIR stands for Universal Application Item Recovery, and there are 4 stand alone .exes for the various U-AIR wizards of Veeam BaR – AD, Exchange, SQL, and Universal. All of these wizards can be installed on the Veeam BaR server or on any Windows system that can communicate with Veeam. They could be installed on an admins desktop or the SQL, Exchange, or Domain Controller servers too.

Normally, the purpose of the U-AIR wizard is to request and kick off a workflow for a Veeam vPower Virtual Lab. Once the request is approved and managed by the VMware/Veeam administrator and the “Lab Manager–like” virtual lab is ready with the fenced off, running backup copy of the VM(s), the U-AIR wizards allow for the restore from the backup copy VM to the original production VM. For SQL VMs in particular, the restore options are shown in the following screen shot:

Watch this 4 minute video to see the normal SQL restore functionality of the wizard. This video skips the workflow request, skips the wait for approval and virtual lab start up, and just shows what is possible from a backup copy of a SQL VM. I also want to mention that this is an agentless solution. You do not need to install and manage agents anywhere with Veeam BaR.

Trick The System for Physical SQL backups

You can skip the workflow process of starting and using the vPower Virtual Lab if you use an undocumented (as far as I know) Admin Switch for the U-AIR wizards. I’ll focus on the SQL U-AIR wizard for the rest of this post, but it is the same for the Exchange and AD wizards as well.

Read the rest of this entry »

VMware engineer Michael White’s post 64 bit is almost here – are you ready? on the Uptime (VMware and Business Continuity) Blog foretells of the future 64 bit requirement of both vCenter and SRM (Site Recovery Manager). White writes:

“I wanted to remind everyone, of what I have already seen floating around the internet, but still important enough to remind.  Our next release of SRM is going to require a 64 bit OS.  This is the same as our next release of VC as it too will require a 64 bit host OS.  This change is required to support the increased capabilities of our products.  As we scale our products to match our customers needs, generally 1 – 2 years in advance of where they will need all the capabilities of a given product we have had to use a 64 bit OS.  This will show itself in increased numbers in things like more simultaneous vSphere client connections.”

To me these new operating system (OS) requirements mean we will see even more instances of vCenter as a VM (virtual machine). It only seems logical that a least path of resistance is to virtualize the management server in order to upgrade, especially considering all have already invested in 64 bit hardware for their hypervisors if they decided to upgrade to vSphere 4 in the first place. To go a step further, I’m willing to argue that it will be more common for an IT Department to justify the cost of additional ESX hosts, even if only dedicated for management, then it will to deploy new servers for physical instances of vCenter.

The looming transition to a console-less ESXi eventually means more management virtual appliances in the future too. Solutions which will continue to need a ESX console or similar will have to substitute their own appliance to operate with ESXi. This means even more justification for additional ESX/ESXi hosts and thus greases the decision to virtualize vCenter as well. I expect to see management clusters of ESX hosts become more common in the future than even the use of management networks today.

ESX hosts have bigger and badder hardware now than ever before allowing for higher consolidation ratios and larger applications to easily run in virtual machines, but it will be interesting to see if the vCenter as a VM best practices change over time. I personally feel that continuing to separate the database from the virtualized vCenter will continue to be a smart choice. Running a separate, and even virtualized, SQL instance ensures not only better performance of vCenter as a VM but enhances DR scenarios. In fact, those that already have the vCenter database on a remote instance will likely have a safer upgrade to the 64 bit vCenter.

The new 64 bit requirements will no doubt make for an interesting migration scenario, and I’m sure we will see some positive and negative opinions. Let me know your thoughts on a 64 bit vCenter as a VM in the future!

The vSphere Enterprise Plus vNetwork Distributed Switch (vDS) has been heralded as, and I might add lives up to it’s reputation of, an administrator’s time saver and single point of virtual networking configuration and visibility across many ESX/ESXi 4 hosts. However, the vDS presents some administrative challenges unique from the traditional vNetwork Standard Switch (vSS) that admins are used to. Specifically, since the vCenter 4 Server actually maintains the vDS configuration, some extra design thinking needs to be built into a vSphere 4 environment where a vDS will be used. If vCenter 4 Server itself will be a virtual machine in the environment with a vDS, the design gets even more involved.

There are a few possible problems to consider. In this post I’ll first cover (with the help of a several others) general VM and vCenter vDS networking issues, but along the way I’ll explore thoughts about designing around a vDS for keeping vCenter as a VM.

Read the rest of this entry »

I haven’t always covered all the vCenter, VirtualCenter, and ESX/ESXi updates in the past. Several updates have been released since the last time I did. VirtualCenter 2.5 Update 6’s announcement caught my attention because of a fix to uploading files with the datastore browser. This issue has been reported in one of the longest comment threads here at VM /ETC. More on that later in this post, but I received the following email notification that VMware VirtualCenter 2.5 Update 6 was released:

VMware VirtualCenter 2.5 Update 6 is Generally Available

We are pleased to inform you that VMware VirtualCenter Server 2.5 Update 6 (English and localized) is generally available as of late night January 29, 2010.

VirtualCenter 2.5 Update 6 provides the following improvements:

• Guest Operating System Customization Improvements
• Support for Firefox 3.x Browsers with VirtualCenter Web Access
• Bug and security fixes

For details regarding the new fixes and improvements, please refer to the release notes.

VirtualCenter Server 2.5 Update 6 is available for download.

For details regarding compatibility, please view vSphere Compatibility Matrixes.

Thanks,
VMware Infrastructure Product Management Team

Some of the highlights for me when reading the Release Notes are:

Read the rest of this entry »

This post is just a quick how to reference for manually changing the VMware Update Manager (VUM) patch repository download location. Admins usually need to do this when the vCenter server is low on disk space on the partition that VUM was originally installed on, but there is a second partition that has enough capacity. To move the VUM patch repository follow the following steps found in the VUM Administrators Guide:

When you install Update Manager, you can select the location for downloading patches. To change the location after installation, you must manually edit the vci-integrity.xml
file.

Procedure

1. Log in to the Update Manager server as an administrator.
   
2. Stop the Update Manager service.
   
   1. Right-click My Computer and click Manage.
      
   2. In the left pane, expand Services and Applications and click Services.
      
   3. In the right pane, right-click the VMware Update Manager Service and click Stop.
      
3. Navigate to the Update Manager installation directory and locate the vci-integrity.xml file.
   
   1. The default location is C:\Program Files\VMware\Infrastructure\Update Manager.
      
4. Create a backup copy of this file in case you need to revert to the previous configuration.
   
5. Edit the file by changing the following fields:
   
   1. yournewlocation
   2. The default patch download location is: C:\Documents and Settings\All Users\Application Data\VMware\VMware Update Manager\Data\
      
   3. The directory path must end with \.
      
6. Save the file in UTF-8 format, replacing the existing file.
   
7. Copy the contents from the old patchstore directory to the new folder.
   
8. Restart the Update Manager service.
   

In order to create customized Windows 2003 and earlier virtual machines (VMs) the Microsoft Sysprep tools need to be added to VMware vCenter (also formerly known as VirtualCenter). Doing so is not a difficult process, but can be a bit confusing if an administrator has never used Sysprep before. Fortunately, VMware has a helpful KB article on the topic that explains where to download the Sysprep files from Microsoft and then where to put the extracted contents of those downloads on the vCenter Server. I’m going to high lite the instructions from VMware for downloading from Microsoft, but then I’ll explain how to get Sysprep from an alternate and arguably easier source – the Windows install CD.

Note that integrating the Sysprep files are still required in all versions of vCenter to customize VMs. This includes vCenter 4 for vSphere. Sysprep is no longer used for Server 2008, however, but VMware has added native customization of Server 2008 VMs in vCenter 4 without adding any additional files.

KB Article 1005593 titled Sysprep file locations and versions not only provides download links and extract to locations but also explains the common symptoms when Sysprep is not installed correctly on vCenter.

• When attempting to customize the deployment of a virtual machine the radio buttons are disabled (greyed out).
• When a virtual machine (VM) is deployed from a Template, you find that the SID is always the same, despite the fact that you chose the option to generate a new SID during Template deployment and guest operating system customization.
• When attempting to create a new virtual machine from a Template in ESX v3.5 you receive the following error message

Warning: Windows customization resources were not found on this server

• Message in the guestcust.log:

deploy doesn’t contain known sysprep files

The KB article explains the cause

Microsoft has a different version of Sysprep for each release and service pack of Windows. According to Microsoft, “You need to use the version of Sysprep specific to the operating system you are deploying”. The differences are not immediately visible in the packaging and documentation of the service packs, so it is necessary to manually investigate.

Use either of the following methods to obtain the appropriate Sysprep files. All instructions in this post assume vCenter has been installed in the default location. Read the rest of this entry »

Admins of heavily consolidated VMware VI 3 Clusters should make plans as soon as possible to download Update 5 of VMware vCenter Server to take advantage of increased performance and scalability. The latest update to vCenter 2.5 was released on July 10 and boasts improvements to support fail over management of up to 80 VMs per ESX/ESXi host in a HA (High Availability) Cluster.

The following details were taken from the VMware VirtualCenter 2.5 Update 5 Release Notes:

What’s New

Support for High Consolidation in VMware HA Clusters – VirtualCenter 2.5 Update 5 includes significant performance and scalability improvements to VMware HA. Use VirtualCenter 2.5 Update 5 for environments with more than 35 virtual machines (VMs) per host in an HA cluster.

For information on the ESX Server host settings required for this scalability improvement, see ESX Server host settings required for environments with up to 80 virtual machines per host in an HA Cluster (KB 1012002).

Upgrading or Migrating to VirtualCenter 2.5 Update 5

This release supports upgrading from VirtualCenter 1.4.1, VirtualCenter 2.0.2 (including Update 1, Update 2, Update 3, Update 4, and Update 5), VirtualCenter 2.5, VirtualCenter 2.5 Update 1, VirtualCenter 2.5 Update 2, VirtualCenter 2.5 Update 3, or VirtualCenter 2.5 Update 4, to VirtualCenter 2.5 Update 5. Review the detailed upgrade and migration instructions and guidelines that are provided in the Upgrade Guide.

Following the above link to KB 1012002 explains that upgrading vCenter 2.5 to U5 is just the start. VI 3 admins also need to make some additional configurations on ESX/ESXi hosts to achieve the 80 VMs per host improvements.

“Starting with the VirtualCenter 2.5 Update 5 release, an ESX Server host in an HA cluster can support up to 80 virtual machines. For all virtual machines to power on on other hosts in the cluster, if hosts within the failover capacity limit fail, you need to ensure that the following parameters in the ESX Server hosts are set with the following values:

Read the rest of this entry »