October 2011 archive

Oct 28 2011

Setting up VMware Auto Deploy for customers (Part 2)

You learned about VMware Auto Deploy’s benefits in part one of our two-part series, but it’s also important to know the vSphere 5 feature’s nuts and bolts and how to set it up for customers.

Auto Deploy takes advantage of the Preboot Execution Environment (PXE) boot feature that is present in many physical network interface cards (NICs). This allows a server to boot from a remote image file using only a physical NIC and without local storage.

A server booting with PXE first obtains an IP address using Dynamic Host Configuration Protocol (DHCP) and then loads a boot image from a Trivial File Transfer Protocol (TFTP) server. Auto Deploy uses PXE booting to download an ESXi image file to a host and its components work to define which image a host should use, customizations and host-specific configuration information.

Auto Deploy relies on software depots that are used to store collections of vSphere Installation Bundles (VIB) and image files that are accessed remotely via HTTP to deploy or update hosts. VIB files are used to deploy the ESXi software and any hardware vendor customizations. The Auto Deploy Server uses the software depot to pull VIBs and image profiles when booting an ESXi host.

Read the full article at searchsystemschannel.com…

Share This:

Oct 28 2011

How VMware Auto Deploy can ease VAR workloads (Part 1)

Although creating new hosts is a common server virtualization task, it is also a tedious process. Solution providers can use VMware Auto Deploy for vSphere 5 to do it much more efficiently.

Installing single hosts isn’t hard for solution providers but configuring multiple hosts can be time consuming. A VAR that has to create a new vSphere host without VMware Auto Deploy typically has to do the following:

1. Locate the installation media for ESX or ESXi and boot the server from it.

2. Follow the setup prompt to set configuration information.

3. Complete the installation and then reboot the server.

4. Verify that management console networking works properly.

5. Add the host to vCenter Server.

6. Configure networking, storage, security and other settings.

In doing all this, you risk making mistakes during the build process and could configure hosts inconsistently. Consistency is very important in a virtual environment both from a security and operational perspective. Once you’ve built and configured a host, another challenge is to back up host configuration data so if a problem occurs and you need to rebuild the host, you don’t have to restart from scratch.

Read the full article at searchsystemschannel.com…

Share This:

Oct 28 2011

vSphere 5’s Storage DRS and storage profile function deliver control over storage resources

The release of VMware Inc.’s vSphere 5 brings many exciting new features and enhancements to the virtualization platform, especially when it comes to storage. Two of the biggest new features in that area are Storage Distributed Resource Scheduler (DRS) and Profile-Driven Storage, which provide some much-needed control over storage resources.

In previous versions of vSphere, Distributed Resource Scheduler balanced VM workloads based on CPU and memory resource utilization. Storage DRS extends this capability to storage, enabling intelligent VM initial placement and load balancing based on storage I/O and capacity conditions within a cluster. Profile-Driven Storage, for its part, ensures that VMs are placed on storage tiers based on service-level agreements (SLAs), availability, performance and capabilities of the underlying storage platform. In this tip, we’ll examine both Storage DRS and the storage profile functionality in detail.

Storage DRS

Similar to the traditional DRS feature, Storage DRS uses a new type of cluster called a data store cluster, which is a collection of data stores that are aggregated into a single unit of consumption. By controlling all of the storage resources, Storage DRS allows intelligent placement of VMs that are powered on, as well as the shifting of workloads from one storage resource to another when needed to ensure optimum performance and avoid I/O bottlenecks. What this means in simpler terms is that, similar to vMotion’s movement of VMs from host to host, VMs can now be moved from data store to data store as well; the decision to move a VM from one data store to another is made by Storage DRS, which tells Storage vMotion to make the move.

Read the full article at searchvirtualstorage.com…

Share This: