
Disclaimer: The views expressed anywhere on this site are strictly mine and not the opinions and views of VMware

Disclaimer: The views expressed anywhere on this site are strictly mine and not the opinions and views of VMware
Recently I’ve been getting questions about upgrading the operating system on the server where vCenter server is installed. For the most part, I’ve gathered information from a group of folks who are somewhat confused and misled on this procedure. So far I’ve heard all types of misinformation on what’s needed and what steps are required. I want to particularly address one of those false statements, that you must create a new vCenter database when upgrading to a new version of windows. I want to make it perfectly clear that you do not have to create a new database.
Now let me help out a bit by clearing things up and providing some substance. Upgrading the Windows operating system where vCenter server is installed from an older version of Windows OS (Windows Server 2003) to a newer version (Windows Server 2008, or Windows Server 2008 R2), doesn’t require a new vCenter Server database. regardless of what the reason may be for the upgrade (whether it’s based on going from a 32-bit to a 64-bit architecture of the OS or for an increase of management capacity for vCenter). The assumption is not accurate that in order to perform this type of upgrade a new database is required, or even going as far as to thinking that it may even be a best approach is incorrect as well.
The creation of a new vCenter database may be acceptable for environments that intend on getting a fresh start, but definitely not something larger environments consider when planning an upgrade of any sort. A new vCenter Server database is a new virtual infrastructure inventory. That means reconfiguration of the logical architecture, adding, and reconfiguring all of the settings of the virtual infrastructure like:
Upgrading the operating system on which vCenter server is installed is something that can be done without the need of creating a new database, and it can also be done in a couple of different ways. In order to upgrade the Windows operating system you should follow Microsoft’s recommendations, but when doing an in-place upgrade all services related to vCenter should be stopped before proceeding.
vCenter Server Services
Another approach to this upgrade would be to simply install vCenter Server in a newly provision system with the current and desired version of Windows. Now in order to do this effectively perform the following steps before installing vCenter Server:
SSL Keys Location
The vCenter Server SSL directory under Windows Server 2008 and Windows Server 2008 R2 is located under a hidden directory called ProgramData located in the root drive.
vCenter Server SSL directory under Windows Server 2008 and Windows Server 2008 R2
I hope this helps those of you looking into performing OS upgrades where the vCenter Server is involved. Let me know if there are any questions or issues. Windows Server 2008 R2 is not currently supported by VMware for vCenter 4.0, but Windows Server 2008 is officially supported. : )
Over the course of past week I was asked a couple of storage related questions in regards to VMFS volumes and LUN partitions. The topic of the questions were based on something that folks with experience, and knowledge of VMware virtualization platforms are aware about. The questions were focused VMFS volumes and how they work, and the reason as why is not a good practice to create multiple VMFS volumes in a LUN that has been partitioned. I wanted to take a moment and try to explain it as simple as I can so here is my take on why we don’t want to use multiple VMFS volumes per LUN. I hope it’s something that can be of help.
VMware’s vStorage VMFS is a clustered file system that is shared among many servers – all or any of which could be writing to a shared LUN. So the access to the LUN’s (which by the way is a single partition) needs to control for certain important functions.
Another important function is that an ESX server powering on a VM. There can’t be confusion about which ESX server is running a VM because only that ESX server can write to the VM’s files (or else the VM files might get corrupted. SO we LOCK the entire LUN (datastore) (which is usually 1 partition) when we startup a VM. VMFS makes a note in the VMFS metadata to indicate which ESX server has that VM running (locked) or as we say the VM is “registered” on that ESX Server.
Another important function is allocating space. When we allocate a block on VMFS we can’t have confusion about whether the block is allocated or not – so we lock the entire LUN .
How does VMware lock an entire LUN? To lock the LUN VMware uses a feature of iSCSI or FC arrays called a SCSI-2 reserve – it’s VMware’s “distributed locking mechanism – the ESX Server requests and the array grants a SCSI-2 reserve to the ESX server allowing that server exclusive access to a LUN. A SCSI-2 reserve is held until the ESX server releases the SCSI-2 reserve (I believe). In VMFS3 VMware tries to hold the reserve for the shortest possible time – just 1 or 2 I/O’s – otherwise of course other ESX servers cannot access the LUN and performance could suffer.
So here’s what I think about multiple VMFS partition: since it’s not possible to grant a SCSI-2 reserve on a single partition (if a LUN had multiple partitions) it doesn’t make sense to have separate VMFS filesystems (i.e., multiple partitions) on one LUN. SCSI-2 reserve works only for the whole LUN. And indeed most VMFS volumes are single partition.
As for thin provisioning these SCSI Reserves apply there too – cause if the VM needs to grow then space needs to allocate for the VM. In order to allocate space ESX server has to get a SCSI-2 reserve granting that ESX host exclusive access to the LUN that the thin-provisioned VM is on so VMFS can allocate more space to the VM. Could be disastrous for performance if VM grows a lot. CAUSE we have to 1) Lock the VMFS LUN with a SCSI-2 reserve 2) allocate space to the VM 3) release SCSI-2 reserve 3) then do actual I/o to VM EACH TIME VM fills up a block and needs a new block.
I hope this makes better sense, to the people that asked. I want to thank to Connie Economou for taking the time to help me simplify the topic. Hope this helps.
Today VMware released a new maintenance upgrade for View 4.0. The new release specifically addresses a number of bugs and known issues found in original release. The issues addressed with the release are focused around enhancing the PCoIP feature, and localization of the View client:
For more detailed information go to the VMware View documentation site
Continuing with the education trend for 2010, VMware Education is about to debut yet another valuable class for the vSphere platform. For those contemplating perusing the VCDX certification, this is one class that would be beneficial to have in your arsenal, though it is not a requirement for the current or future VCDX Certification track. The VMware vSphere Design Workshop class will expose you to the design methodology and criteria needed in designing vSphere architecture.
The class is targeted to professionals involved in pre and post technical sales as well as infrastructure design. Prerequisites include extensive vSphere administration knowledge.
The course outline includes the following topics:
Module 1: Course Introduction
Module 2: Design Process Overview
Module 3: ESX/ESXi Host Design
Module 4: vSphere Virtual Datacenter Design
Module 5: vSphere Network Design
Module 6: vSphere Storage Design
Module 7: Virtual Machine Design
Module 8: Management and Monitoring Design
Design Workshop
This is definitely on of my favorite classes, as it takes a different approach to every aspect of the virtual infrastructure. I recommend it!.
For more information about this class, and schedule go to the VMware Education site. Enjoy! : )
Here is a topic that many VMware customers often ask about, “How do you I delete old data from the vCenter Server database”. It’s no secret the vCenter database grows on a day to day basis and overtime some of the stored information becomes outdated. That doesn’t mean the old information is useless, as it may need to be available for auditing purposes. The vCenter database is capable of reaching some significantly large sizes, depending on the size of the managed environments. That can have an impact on the performance of the vCenter Server. When the data stored in the database is no longer relevant to the state of the environment, removing the old data can do some good. The procedure on how to properly remove data from the vCenter database was published by VMware in a KB article that is publicly accessible on the company’s site. The procedure is not something that any administrator could perform or should normally perform as not every virtualization administrator poses DBA skills. The KB article is intended for experience DBA’s, as it deals with working with a third party relational database management system and not a VMware oriented product. The awesome fact here is that VMware has put together a video of the procedure, which makes the procedure very easy to follow and execute by pretty much anyone with the the right access to the systems involved in the procedure, including virtualization administrators without DBA skills. The video is an excellent addition to the step by step KB article.
Watch the video listed below, and if you find it useful, subscribe to VMware KBTV channel on You Tube for many more KB based video. Enjoy!
Purging Old Data from vCenter Server Database Procedure
© 1969 Punching Clouds All Rights Reserved