Posts Tagged ‘vSphere’

Veeam Reporter 4.0 Free Edition

August 16th, 2010

SnagIt CaptureToday, Veeam has launched a new free version of an existing product which you may already be familiar with: Veeam Reporter Free Edition.  Veeam Reporter is an enterprise virtual infrastructure tool which is best described by Veeam on their product page:

Veeam Reporter™ discovers, documents and analyzes your entire virtual infrastructure. It maintains a complete history of all objects, settings and changes. And it trends performance and utilization. So you can really understand your virtual infrastructure—past, present and future.

When it comes to documenting and reporting on your virtual infrastructure, Reporter does it all.

This new free version contains most of the features of the full version.  The free edition can easily be upgraded to the full version of Veeam Reporter to gain these additional capabilities (A features comparison can found here):

  • Capacity planning (report pack)
  • Historical change management (beyond the most recent 24 hours)
  • Microsoft Visio reports for multipathing, network, vMotion, and datastore utilization
  • Full access to archive data—to create custom reports or update your configuration management database (CMDB)
  • Full dashboard capabilities
  • Automatic report distribution

I was invited by Veeam to take a look at the beta version of Veeam Reporter Free Edition.  I’ve captured some of my experience and documented it here.

Installation

Installation of Veeam Reporter Free Edition is fairly straightforward but I should disclose that I’m working with a beta (pre GA) version.  I installed on Microsoft Windows Server 2008 R2 Standard (64-bit only) which is my preferred platform, if supported by the vendor’s product (Veeam Reporter supports it).  Veeam Reporter requires Microsoft .NET Framework 3.5.1.  In Windows Server 2008 R2, this is installed as a Feature:

SnagIt Capture

If installing the Veeam Reporter’s Web UI (the default), the IIS Role is also required during the .NET Framework instllation…plus a few extra roles:

 SnagIt Capture

SnagIt Capture

During the beta, I ran into a JavaScrip error message after the installation was complete:

8-15-2010 8-45-45 PM

As it turns out, the issue has nothing to do with JavaScript, rather, the Static Content Role must be installed for IIS:

8-16-2010 6-31-57 PM

During the Veeam Reporter installation routine, I also installed the Microsoft PowerShell component which is optional:

SnagIt Capture

The Veeam Reporter PowerShell snap-in enables users to perform reporting tasks by running single cmdlets or custom automation scripts via the command-line interface.  The PowerShell SnapIn ReporterDBSnapIn is installed which adds the following Veeam Reporter specific cmdlets to the PowerShell environment:

CONNECT-VRVISERVER
DISCONNECT-VRVISERVER
GET-VRVM
GET-VRVMHOST
GET-VRDATASTORE
GET-VRRESOURCEPOOL
GET-VRCLUSTER
GET-VRSNAPSHOT
GET-VRCURRENTDATE
SET-VRCURRENTDATE

As is quite common with virtualization management tools, including VMware vCenter itself, a back end database is required for the storage of datacenter information.  Veeam Reporter has the ability to leverage an existing Microsoft SQL Server.  In the absence of a dedicated SQL server, Veeam Reporter will install Microsoft SQL Express and integrate with it locally.  Installation of a local SQL Express instance takes quite some time as the necessary SQL binaries (including SP1) are downloaded at this time (this also implies internet connectivity from the Veeam Reporter server is required).

SnagIt Capture

A logoff/logon is required at the end of the installation as opposed to a system reboot:

SnagIt Capture

Configuration

Now that the installation is complete, the next step is to configure Veeam Reporter Free Edition.  There’s really not much to the initial configuration or data collection.  Add to that, the installation and data collection process is agentless – a definite plus. 

So before any data can be displayed, it needs to be collected from the vCenter Server(s).  This is handled by creating a Collection Job which points at the vCenter Server and pulls in the data that Veeam uses.  A collection job should be scheduled to run periodically so that it grabs updated data at regular intervals.  I set up a Collection Job to run automatically once per day at midnight.  For the purposes of instant gratification, I manually ran the job to get some data:

8-16-2010 8-54-55 PM

In addition to configuring a Collection Job, I also set up a few of the ancillary items one would commonly find in reporting and management applications such as an Email server.

Now that I have some data, I can start creating useful reports and that’s where the fun begins.  I will cover some of the reports in the next update so stay tuned.

In the mean time, download your copy of Veeam Reporter Free Edition today and get started!

 

Free Book – vSphere on NetApp Best Practices

August 2nd, 2010

Hello gang!  For anyone who doesn’t specifically follow the NetApp blogs, this is just a quick heads up to let you know that NetApp has updated its popular NetApp and VMware vSphere Storage Best Practices book and is offering 1,000 free copies of the new Version 2.0 edition

The free copies are available while supplies last so get registered for yours soon!

vSphere 4.1: Multicore Virtual CPUs

July 25th, 2010

With the release of vSphere 4.1, VMware has introduced Multicore Virtual CPU technology to its bare metal flagship hypervisor.  This is an interesting feature which had already existed in current versions of VMware Workstation.  VMware has consistently baked in new features in its Type 2 hypervisor products, such as Workstation, Player, Fusion, etc., more or less as a functionality/stability test before releasing the same features in ESX(i).  VMware highlights this new feature as follows:

User-configurable Number of Virtual CPUs per Virtual Socket: You can configure virtual machines to have multiple virtual CPUs reside in a single virtual socket, with each virtual CPU appearing to the guest operating system as a single core. Previously, virtual machines were restricted to having only one virtual CPU per virtual socket. See the vSphere Virtual Machine Administration Guide.

VMware multicore virtual CPU support lets you control the number of cores per virtual CPU in a virtual machine. This capability lets operating systems with socket restrictions use more of the host CPU’s cores, which increases overall performance.

Using multicore virtual CPUs can be useful when you run operating systems or applications that can take advantage of only a limited number of CPU sockets. Previously, each virtual CPU was, by default, assigned to a single-core socket, so that the virtual machine would have as many sockets as virtual CPUs.

You can configure how the virtual CPUs are assigned in terms of sockets and cores. For example, you can configure a virtual machine with four virtual CPUs in the following ways:

  • Four sockets with one core per socket (legacy, this is how we’ve always done it prior to vSphere 4.1)
  • Two sockets with two cores per socket (new in vSphere 4.1)
  • One socket with four cores per socket (new in vSphere 4.1)

VMware defines a CPU as:

The portion of a computer system that carries out the instructions of a computer program and is the primary element carrying out the computer’s functions.

VMware defines a Core as:

A logical execution unit containing an L1 cache and functional units needed to execute programs. Cores can independently execute programs or threads.

VMware defines a Socket as:

A physical connector on a computer motherboard that accepts a single physical chip. Many motherboards can have multiple sockets that can in turn accept multicore chips.

One of the benefits of multicore which physical computing had was increased density of the hardware.  VMs do not share this advantage as they are virtual to begin with and have no rack footprint to speak of.

VMware’s benefit statement for this feature is a legitimate one and is the primary use case.  It’s the same benefit which applied when multicore (as well as hyperthreading to some extent) technology was introduced to physical servers.  What VMware doesn’t advertise is that the limitation being discussed usually revolves around software licensing – a per-socket license model to be precise which is what many software vendors still use.  For example, if I own a piece of software and I have a single socket license, traditionally I was only able to use this software inside of a single vCPU VM.  With Multicore Virtual CPUs, Virtual Machines have now caught up with their physcial hardware counterparts in that a single socket VM can be created which has 4 cores per socket.  Using the working example, the advantage I have now is that I can run my application inside a VM which still has 1 socket, but 4 cores for a net result of 4 vCPUs instead of just 1 vCPU.  I didn’t have to pay my software vendor additional money for the added CPU power.  To show how this translates into dollars and cents, let’s assume a per socket license cost of my application to be $1,000 and then extrapolate those numbers using VMware’s example above of how CPUs can be assigned in terms of sockets and cores:

  • Four sockets with one core per socket = $1,000 x 4 sockets = $4,000 net license cost, 4 CPUs
  • Two sockets with two cores per socket = $1,000 x 2 sockets = $2,000 net license cost, 4 CPUs
  • One socket with four cores per socket = $1,000 x 1 socket = $1,000 net license cost, 4 CPUs
  •  

    Now, all of this said, the responsibility is on the end user to be in license compliance with his or her software vendors.  Just becasue you can do this doens’t mean you’re legally obliged to do so.  Be sure to read your EULA and check with your software vendor or reseller before implementing VMware Multicore Virtual CPUs.

    Implementation of Multicore Virtual CPUs was quite straightfoward in VMware Workstation.  Upon creating a new VM or editing an existing VM’s settings, the following interface was presented for configuring vCPUs and cores per vCPU in VMware Workstation.  In this example, a 2xDC (Dual Core) configuration is being applied which results in a total of 4 CPU cores which will serve the VM’s operating system, applications, and users. Note that here, the term “processors” on the first line translates to “sockets”:

    7-25-2010 11-39-53 AM

    Making the same 2xDC CPU configuration in vSphere 4.1 isn’t difficult but nonetheless it is done differently.  Configuring total vCPUs and cores per vCPU is achieved by applying configurations in two different areas of the VM configuration. The combination of the two configurations produces a mathematical calculation which ultimately determines cores per vCPU.

    First of all, the total number of cores (processors) is selected in the VM’s CPU configuration.  This hasn’t changed and should be familiar to you.  The number of cores (processors) available for selection here is going to be 1 thru 4 or 1 thru 8 if you have Enterprise Plus licensing.  I’ve purposely included the notation of the VM hardware version 7 which is required. An inconsistency here compared to VMware Workstation is that the term “virtual processors” translates to “cores”, not “sockets”:

     7-25-2010 11-41-09 AM

    Configuring the number of cores per processor is where VMware has deviated from the VMware Workstation implementation.  In ESX and ESXi, this configuration is made as an advanced setting in the .vmx file.  Edit the VM settings, navigate to the Options tab, choose General in the Advanced options list. Click the Configuration Parameters button which allows you to edit the .vmx file on a row by row basis.  Click the Add Row button and add the line item cpuid.coresPerSocket. For the value, your going to supply the number of cores per processor which is generally going to be a value of 2, 4, or 8 (Enterprise Plus licensing required).  Note, using a value of 1 here would serve no practical purpose because it would configure a single core vCPU which is what we’ve had all along up until this point:

    7-25-2010 11-45-38 AM

    As a supplement, here are the requirements for implementing Multicore Virtual CPUs:

    • VMware vSphere 4.1 (vCenter 4.1, ESX 4.1 or ESXi 4.1).
    • Virtual Machine hardware version 7 is required.
    • The VM must be powered off to configure Multicore Virtual CPUs.
    • The total number of vCPUs for the VM divided by the number of cores per socket must be a positive integer.
    • The cpuid.coresPerSocket value must be a power of 2. The documentation explicitely states a value of 2, 4, or 8 is required, but 1 works as well although as stated before it would serve no practical purpose.
      • 2^0=1 (anything to the power of 0 always equals 1)
      • 2^1=2 (anything to the power of 1 always equals itself)
      • 2^2=4
      • 2^3=8
    • When you configure multicore virtual CPUs for a virtual machine, CPU hot Add/Remove is disabled (previously called CPU hot plug).
    • You must be in compliance with the requirements of the operating system EULA.

    This feature rocks and I think customers have been waiting a long time for it.  Duncan mentioned it quite some time ago but obvioulsy it was unsupported at that time.  I am a little puzzled by the implementation mechanisms, mainly the configuration of the .vmx to specify cores per CPU.  I suppose it lends itself to scriptability and thus automation, but in that sense, we lack the flexibility to configure cores per CPU with guest customization when deploying VMs from a template.  Essentially this means cores per CPU needs to be hard coded in each of my templates or cores per CPU needs to be manually tuned after deploying each VM from a template.  When I take a step back, I guess that’s no different than any other virtual hardware configuration stored in templates, but with the cores per CPU setting being buried in the .vmx as an advanced setting, it’s that much more of a manal/administrative burden to configure cores per CPU for each VM deployed than it is to simply change the number of CPUs or amount of RAM.  It would be nice if the guest customization process offered a quick way to configure cores per processor.

    GoGo Inflight Internet

    July 24th, 2010

    During a recent trip, I decided to use GoGo Inflight Internet aboard a Delta Airlines flight.  I’ve only used the service once before and that is merely because the service typically isn’t offered on the flights I am on.  Both the reliability and latency of service far exceeded my expectations.  I used the service for a little over three hours and lost only 77 frames: 

    Ping statistics for w.x.y.z:
    Packets: Sent = 8650, Received = 8573, Lost = 77 (0% loss),
    Approximate round trip times in milli-seconds:
    Minimum = 107ms, Maximum = 3220ms, Average = 205ms

    I was easily able to upgrade a vCenter Server and build an ESXi host to vSphere 4.1, as well as process a bunch of email I had fallen behind on.  The cost was $9.95 and given my satisfaction of the service and what I was able to accomplish, it was well worth the price.  I wish more flights offered this service.

    Two Thumbs Up! 😎

    vSphere Cluster Showing Noncompliant on the Profile Compliance Tab

    June 24th, 2010

    To troubleshoot a vSphere cluster showing Noncompliant on the Profile Compliance tab, check the following:

    FT logging NIC speed is at least 1000 Mbps
    At least one shared datastore exists
    FT logging is enabled
    VMotion NIC speed is at least 1000 Mbps
    All the hosts in the cluster have the same build for Fault Tolerance
    The host hardware supports Fault Tolerance
    VMotion is enabled

    Read more at: http://kb.vmware.com/kb/1017471

    vSphere Upgrade Prerequisites Checklist

    May 27th, 2010

    Upgrading your virtual infrastructure to vSphere?  Be sure to check out this handy reference from VMware:  vSphere Upgrade Prerequisites Checklist.  There are several areas which need to be considered and this document covers them all, including both requirements and recommendations.  If you’re a consultant who visits new customer sites on a regular basis, it wouldn’t be a bad idea to bring this with to each engagement, or at least a condensed version of it.

    Happy Birthday vSphere!

    May 21st, 2010

    birthday-cake

    I was reminded by today’s vCalendar page that vSphere was launched by VMware one year ago today.  Happy Birthday Buddy – you set the bar which all other hypervisors aspire to be at one day.

    On this day in 2009, VMware vSphere, the next generation datacenter virtualization product and successor to Virtual Infrastructure 3 (VI3), was released boasting approximately 150 new features, new license tiers, and an amazing 350,000 I/O operations per second (IOPS). vSphere is a 64-bit only ESX host OS.

    Don’t have a vCalendar yet?  Get one!