h1

In-the-Lab: Full ESX/vMotion Test Lab in a Box, Part 5

September 28, 2009

Installing vCenter Update Manager

Update Manager is VMware’s patch management utility for your virtual environment. As patches become available for your virtual machines (based on the guest operating systems selected in the VM definition) Update Manager (UM) downloads and indexes them for deployment to your virtual environment. Under vCenter’s control, UM can apply patches to on-line and “off-line” virtual machines alike. For off-line VM’s, UM disables the network connection(s) to preserve isolation, fires-up the VM, and applies the patches through the VMware Tools linkage.

SOLORI Note: It is very important that a virtual machine’s “Guest Operating System” selection match the guest OS exactly. Update Manager uses this information to choose appropriate patches for the VM. For instance, while Suse Linux Enterprise Server 11 (SLES 11) may actually work as a guest type for an OpenSuse 11.2 beta VM, selecting SLES 11 as the actual “Guest Operating System” type would be a mistake as UM may try to stage SLES 11 patches to your OpenSuse virtual machine – potentially rendering the OS unworkable. Avoid this by choosing the appropriate “Other” virtual machine guest operating system type.

Just like vCenter Server, Update Manager starts with the local language selection, and then it asks for vCenter Server’s information: this allows Update Manager to run separately from vCenter Server. Since our UM runs on the same “physical” machine as vCenter Server, we will use 127.0.0.1 as the IP address and offer the local Administrator’s credentials for access. Again, your production security policy may require a separate, dedicated user for Update Manager. In a domain, this user would need to belong to a group with admin rights to vCenter – we’ll save that for another post…

Assuming the IP address and credentials check-out, the next step is to identify the existing Data Source Name for vCenter’s database. The default should appear as “VMware Virtual Center (MS SQL)” in the drop-down box. Had your installation pointed to a full-blown Microsoft SQL installation, the DNS would have been setup upon installation of VMware vCenter. Likewise, were this a stand alone installation of Update Manager, you would have needed to have created the DSN prior to installation (or now via the Control Panel.) We select the default DSN and continue.  Likewise, since we have the default installation of MS SQL Express, we’ll leave the database credentials blank and proceed.

The next step identifies the first case where robust host naming is necessary: selecting the IP or name reference for Update Manager. Since Update Manager is an IP/hostname addressable resource, it is imperative that the IP address either be static or the hostname be properly configured in all DNS servers that a referenced by the ESX, ESXi and vCenter servers. If this is not the case, cancel the Update Manager installation and get right with DNS (including forward and reverse records) before continuing – it will save a ton of headaches.

VMware vCenter Update Manager port and name settings.

VMware vCenter Update Manager port and name settings.

Assuming DNS is in order, we’ll select the FQDN of our vCenter’s hostname. If you cannot select the FQDN, you must modify your “Computer Name” in the Control Panel to correspond to its FQDN, reboot and restart the Update Manager installation. If, as above, your FQDN is selectable, choose it and click “Next” to continue.

SOLORI’s Hint: If DNS configuration is problematic in your lab, try installing Microsoft DNS on the vCenter server VM and create a suitable lab zone. Likewise, create a corresponding in-addr.arpa zone to insure proper forward and reverse name resolution. Don’t forget to update your ESX, ESXi and vCenter instances to point to this new facility (exclusively). This is easier than managing a second VM specifically for DNS and will not have any adverse affects on your lab.

Then next step is configuring the Update Manager’s “Destination Folder” for the application itself and for the downloaded patches. We will accept the default path for the application – substituting the M: drive for the default C: drive entry. Likewise, for the downloaded patches folder, we’ll modify the path to store patches on the N: drive with a path of “\VMware\VMware Update Manager\Data” and click “Next.”

At this point, all user input is complete and the installer will continue until Update Manager has been completely installed. The last thing the installer will do is register Update Manager with vCenter Server and startup the Update Manager service. vCenter Server Update Manager is now completely installed and ready for use.

Installing VMware vCenter Converter

VMware vCenter Converter facilitates the import and conversion of virtual and physical machines. By installing this tool to our vCenter Server, we enable an enterprise grade utility for converting physical and virtual machines using vCenter and the VI Client as a common interface. By selecting the “typical” setup, we will not install the converter agent which is used to convert a running virtual/physical machine. Within an Active Directory domain, a properly credentialed vCenter with Converter can “reach out” and convert any domain-controlled physical (or “foreign” virtual) machine without incurring down-time.

Besides the selecting the “typical” setup, we are directing the storage for Converter to our M: drive.

Installing vCenter Guided Consolidation

With Converter installed, this optional extension to vCenter Server allows for quick acquisition, analysis and conversion of any virtual or physical machine into our virtual datacenter(s). Guided Consolidation allows vCenter to monitor one or more prospective conversion machines actual utilization over an administratively determined period and deliver an impact analysis specifying the candidate’s suitability for virtual consolidation and its impact on the virtual datacenter.

After selecting the proper localization and EULA, we will modify the application path to point to our M: drive. The vCenter Collector Service requires access to the local machine at the administrator level. If you are using Active Directory credentials in your follow-along installation, make sure and use an AD user that ALSO has local administrator rights to the vCenter machine – otherwise expect problems. For our purposes, we’re using the local administrator account.

After selecting the default ports, we will input the FQDN of the vCenter server and local administrator credentials to register the service with vCenter. Likewise, we will select the FQDN as the machine’s identity and continue – then sit back while the installed finishes.

Installing vSphere Client to vCenter Server

Since vCenter Server is RDP reachable, it is convenient to install the vSphere/VI Client to the vCenter server to “locally” manage your VM’s. While this step is optional, it can come in handy in a pinch – or if your normal desktop is Linux-based. While it does consume disk space after installation, it creates no load on the vCenter server while not in use; therefore it is a good practice to adopt.

After accepting the EULA, enter your personal and organization information (if it is not already correct) and click “Next.” Since we have installed Update Manager, we have no real use for the “Host Update Utility” on our vCenter server, so leave it unchecked (that application is really for workstations and field laptops.) Again, we want to install the application files to our M: drive and wait for the installer to finish.

Now that the final installable item is installed, use the VI Client to disconnect the CD-ROM/ISO and change the CD-ROM device type to “Client Device” to remove the dependency on the ISO image. That’s it, technically, but we recommend a reboot of the OS for good measure and to make sure all of the dependent service startup automatically on reboot. Assuming all is well in your Event Viewer after the reboot, your services list should look something like this:

VMware and SQL services after startup.

VMware and SQL services after startup.

Tip: Remember that Update Manager is a patch manager for all of the supported operating systems including several application vendors plus VMware applications (including ESX and ESXi.) Therefore, once Update Manager starts its first patch update there will be a load on the storage system and Internet link. It’s a good time to go for coffee before starting the next step…

Congratulations! A Full-Featured vCenter Server is Installed

Now, let’s connect to vCenter for the first time. Using the vSphere Client (VI Client 4.0) enter the IP address of the vCenter Server and administrator credentials in the vClient requester and login. You will be presented with a “Certificate Warnings” pop-up informing you that the certificate associated with the vCenter Server may have a problem:

VMware Certificate Warning

VMware Certificate Warning

Since the default certificate has not been replaced with a “real” certificate, let’s just accept the certificate and advise the client not to display warnings about this host again. If your DNS is not setup correct (or possibly not up-to-date) you will get a warning about one of the additional services (Update Manager) which will need to be corrected before continuing:

VMware Update Manager DNS Error - good name resolution is important in vSphere!

VMware Update Manager DNS Error - good name resolution is important in vSphere!

Once DNS is up-to-date, login using the vCenter hostname and acknowledge/ignore the security warning.  VMware vCenter will now greet you with the message of the day stating that you have 60-days to license or remove vCenter (plenty of time for a discovery lab!)

VMware vCenter MOD - License Notice

VMware vCenter MOD - License Notice

vCenter’s “Getting Started” tab will prompt you to create a “datacenter” – the basic container for ESX/ESXi servers, clusters and subordinate virtual machines. Let’s oblige vCenter by clicking on the “Create a datacenter” hyperlink and name the new datacenter “ESX-on-ESX” and click on the datacenter in inventory as prompted:

New Virtual Datacenter with Empty Inventory

New Virtual Datacenter with Empty Inventory

With our datacenter active, it’s time to add a couple of ESXi hosts to the equation. Using two clones of our esxi-master image, we right-click on the “ESX-on-ESX” datacenter and select “Add host…” and enter the first ESXi host’s FQDN and the root credentials:

vCenter will complain about the SHA1 thumbprint of the host – select “Yes” to trust the host and continue. When asked to assign a license, use the “Evaluation Mode (No License Key)” which will begin the 60-day trial for this ESXi instance (effective the date installation of ESXi was completed, i.e. today since we cloned the install prior to completing the installation and initial configuration). We will repeat this process for our second ESXi server and notice that the SHA1 keys are indeed different between the clones.

It takes vCenter a minute or two to inventory the ESXi hosts and make them available for management through vCenter. Once complete, vCenter will warn that no datastores have been configured between the two hosts:

To be useful, our ESX hosts need storage...

To be useful, our ESX hosts need storage...

To complete this installment of the series, we’ll add our “Virtual-Machines” datastore from VSA’s volume0. To do so, we need to create a new VMkernel interface on both of the ESXi servers specifically for VM storage. This network will be connected to a new vSwitch which is fed by vmnic2:

The VMNICs exspose connected networks to assist selection of the proper NIC. Notice the VLAN identification for tagged traffic on the 802.1q-connected NIC (vmnic1).

The VMNICs exspose connected networks to assist selection of the proper NIC. Notice the VLAN identification for tagged traffic on the 802.1q-connected NIC (vmnic1).

We will call this port group “VMkernel Storage” and select no additional options for the interface. For the IP address, we will use the uniquely assigned IP addresses on the storage network and associated subnet mask. Once the IP addresses are added and the vSwitch/port groups enabled, we need to return to our VSA and enable “read-write” and “root” access to the NFS file system associated with out “Virtual-Machines” datastore: this must be done prior to the “Add Storage…” step in vCenter.

For vMotion and clustering to work properly, the NFS file system must be named the same on each ESX server. For iSCSI volumes, the name is provided through the VMFS3 mounting process, but for NFS the file system is mounted and named manually – creating an opportunity for mistakes. Fortunately, the host profiles feature can help us find and correct such mishaps. For our lab, we have chosen the mount name of “Virtual-Machines-VSA01” to match the root ESXi mount (just in case we want to vMotion between the root host.)

A look at our virtual datacenter courtesy of "Storage Views" in vCenter. Here we can see the interconnection of the hosts and storage including network dependencies.

A look at our virtual datacenter courtesy of "Storage Views" in vCenter. Here we can see the interconnection of the hosts and storage including network dependencies.

With a datastore added, we’ve completed the basic installation of vCenter and a pair of (virtual) ESXi hosts. In the next installment of our series, Part 6, we will utilize “host profiles” to mirror the provisioning of our ESX servers and make sure they are up-to-snuff before turning-up a test virtual machine and attempting our first vMotion in the lab-in-a-box. Stay tuned…

Pages: 1 2 3

6 comments

  1. Good Job !!
    and I am still waiting XD

    and BTW , may I translate this series articles to Chinese and post in my Blog ?

    Like


    • Eric:

      Thanks, and yes – feel free to reproduce this series in the Chinese language provided proper attribution to all sources referenced in the original is maintained and links back to the original SOLORI post(s) are included (see our copyright standard). A “reproduction” notice at the bottom of each page with links back to the source would be appropriate.

      Once your Chinese version is complete, let us know and we’ll link back to it from SOLORI’s site to facilitate SEO. We’ll be releasing Part 6 soon – getting into the “recursive” vMotion capability of this lab series.

      Regards,
      Collin C. MacMillan
      Solution Oriented LLC

      Like


  2. very nice blogs, I learned alot from these 5 parts so far. I want to use the storage appliance you are recommending in this or even just SOlaris 10 on a hardware or as as VM, but I did alot of research but I donot see any write ups on ZFS and MS VSS backups, like Active Directory or Exchange. Suppose I have an ESX with the Solaris VM running for ZFS and presending the datastore to ESX and then I have an Active Directory VM and an Exchange 2007 or 2010 server as a VM both using the ZFS datastore, then is there a way to integrate the MS VSS write with the ZFS snapshots? that way I will know the backups are consistant with the application meaning if I do a restore the database of exchange or logs of exchange will recover without any problems. This is the only problem or grey area i am dealing with right now. Once again thanks again for a very nice write up 🙂

    Farid

    Like


    • Farid:

      Thanks for the comment. The ZFS-based NexentaStor solution (licensed, with VM Data Center plug-in) integrates well into VMware, Hyper-V and Xen environments where VSS agents provide Windows file system quiescence (VSS) through VM Data Center API calls to the hypervisor. This allows for clean, NexentaStor Appliance-driven snapshots on a per-VM or per datastore basis (assuming your VSS writers are in place).

      Restoring from a snapshot – even application consistent ones – can have application-specific requirements. For instance, AD virtual machines may require one restoration process and Exchange 2007 yet another – even though VSS is a commonality in both snapshot-driven back-up solutions. If your virtual environment is more complex (i.e. coordinated data sources) syncing the snapshots between sources will be required to result in consistent systemic recovery instead of a bunch of unsynchronized, individual recovery points.

      Fortunately, the open aspect of NexentaStor allows for complex management scripts (from a central management agent, say a Windows server like vCenter or Linux server like vMA) to coordinate and orchestrate many sequential events to insure the needs of your environment are met. These scripts could be simple – occupying 20-30 lines of script code – or very complex depending on your needs, environment and number of VM’s and/or physical machines it is necessary to coordinate (synchronous backup).

      Without testing in your specific environment, it is impossible to promise “recovery without any problems” and the amount of tuning you will need to do to your process will be dependent on the complexity of the application. Likewise, it may be that VMware Data Recovery or a third-party backup solution like Veeam Backup and Replication would offer more/additional value than VM Data Center alone, given their ability to offer file-level recovery. If image-level recovery fits your needs, you should trial NexentaStor and VM Data Center for yourself for 45-days and see how it fits your application.

      We’ll be running some in-depth looks at VM Data Center and NexentaStor towards the end of March, 2010.

      Like


      • What About something like this…

        VMWare vSphere Essentials Plus for 3 ESX hosts

        ESX Host1:
        Hardware-
        HP DL360 with Array controller with 6x SAS Drives setup in a raid5 with hot-spare
        4-6 Gig ethernet ports

        Software:
        ESXi hypervisor
        NexentaStor Enterprise Silver Edition – 4TB (VM) controlling the Raid5 logical volume

        ESX Host2:
        Hardware-
        HP DL360 with Array controller with 6x SAS Drives setup in a raid5 with hot-spare
        4-6 Gig ethernet ports

        Software:
        ESXi hypervisor
        NexentaStor Enterprise Silver Edition – 4TB (VM) controlling the Raid5 logical volume

        Now, both NexentaStor are controlling local DAS or the array logical drive. I want to setup 2 VIPs on the nexenta VM’s on the storage side.

        so VIP1=
        Nexenta1 – Active
        Nexenta2 – Passive

        so VIP2=
        Nexenta2 – Active
        Nexenta1 – Passive

        now, on ESX1 I can setup a VM lets say Active Directory 1 and point its storage to VIP1, on ESX2 I can setup another VM lets say another AD server and point its storage to VIP2. So AD1 on ESX1 is accessing storage on Nexenta1 and AD2 on ESX2 is accessing Storage on Nexenta2. Now, I want the 2 Nexenta in the back end to setup a lets say syncronous mirror or like software raid-1 across the 2 nexenta’s. so when AD1 writes or delets anything from its storage on nexenta1 that is replicated to nexenta2 in realtime and same with AD2. Now lets say the ESX1 server goes offline for anyreason, it will bring down the AD1 nexenta1 along with it. Now the VMWare HA will kick in and move the AD1 VM to the ESX2, at the same time I want the nexenta2 on ESX2 to take the nexenta 1’s VIP as well, so now nexenta2 responds to both vips, vip1 and vip2. Now when the AD1 machine is on ESX2 it will acess its data on VIP1 which is now on nexenta2. Sorry for long text but this is what I have in mind. Wondering if this is doable in nexenta and esx.

        The last piece is I want to setup a 3rd ESXi in DR somewhere, and it has its own nexenta3 VM and its got same kinda hardware, and i want to do async replication to the 3rd ESX in DR using delta changes only to save bandwidth. so in case of Primary Site going down I will failover to DR and bring the 2 AD servers in ESX3’s online using the data on the nexenta3.

        As far as backup goes, can I use the Nexenta Delorean 2.0 and install the windows client in the AD1 and AD2 VM’s and do backup that way? is the Nexenta Delorean 2.0 considered a snapshot backup or is it like disk to disk backup? if its snapshot then that would be nice if its disk to disk backup then in that case I can use any backup software out there that supports ESX, like the new backup exex 2010 with deduplicaiton and offsite replication built right in to their disk to disk backup.

        thanks,
        Farid

        Like


  3. […] we can use for rapid deployment in case we want to expand the […]      by In-the-Lab: Full ESX/vMotion Test Lab in a Box, Part 5 « SolutionOriented Blog September 28, 2009 at 6:34 pm […]

    Like



Comments are closed.

%d bloggers like this: