Assigning vSphere security access controls

Security is critical in a vSphere environment. Virtual machine (VM) architecture, access methods and management is much different from that for physical servers. Because VMs are encapsulated into a single file that resides on a shared data store, additional attack vectors need to be secured. Further, any change or operation in a virtual environment can have a ripple effect on other residing VMs because all share common infrastructure components. Consequently, having proper security access controls in place is paramount to protect hosts and their VMs.

Because they have multiple components, virtual environments are secured in layers. You can do much of the work to secure an environment through vCenter Server, which provides centralized authentication and authorization services at many different levels inside vSphere. VCenter Server features four main components:

  • Privileges. A privilege enables or denies users access to perform actions in vSphere.
  • Roles. A role is a set of privileges that can be assigned to a user or group.
  • Users and groups. Users and groups are used in permissions to assign roles from Active Directory (AD) or local Windows users/groups.
  • Permissions. A permission is assigned to an object in vSphere and is composed of users/groups and a role.

Read the full article at searchsystemschannel.com…

Share This:

Data backup application choices for backing up virtual server environments

Traditional data backup procedures used with physical servers typically consist of using an operating system (OS) agent running on each server to be backed up. But virtualization technology changes everything, and introduces more options and flexibility when backing up your servers.

This article will look at how data backup applications that were originally developed to back up physical systems and how they have adapted to support virtual server environments. You’ll also learn about data backup applications that were developed specifically for virtualization, and additional methods that are available for backing up virtual machines (VMs).

Read the full article at searchdatabackup.com…


Share This:

Test ESXi 4.1 today, migrate smoothly from ESX tomorrow

VMware has long claimed that ESXi will one day be the Palo Alto-based company’s main hypervisor, and the time has come for ESX to begin to gracefully make its exit. The recent release of VMware vSphere 4.1 will be the last release to include the ESX version of VMware’s hypervisor, which may not make ESX fanboys happy. The improvements in ESX 4.1, however, demonstrate that the time to start switching is now.

In a recent Virtualization Viewpoints column, I wrote about drawbacks of VMware ESXi and why widespread adoption of ESXi is not a reality. Some of the problems with ESXi included:

  • No official support for booting ESXi from a storage area network (SAN),
  • no Web-based console to manage virtual machines (VMs),
  • no support for scriptable installations, and
  • no support for Active Directory (AD) integration.

The article also outlined several suggestions for making ESXi more attractive to administrators used to working with ESX. While I have always preferred ESX over ESXi, I am now recommending that you start using ESXi and plan on migrating all of your current ESX installations to the ESXi platform.

Read the full article at searchvmware.com…

Share This:

Using VMware vSphere as a private cloud computing platform

If you’re involved in virtualization, you probably can’t go a day without hearing the word cloud – and I don’t mean as part of your weather forecast. If you pay attention to companies like VMware and EMC, it seems as though everything is migrating toward the cloud — and it’s not a matter of if your environment will enter the cloud but when.

Today, virtualization seems to have taken a back seat to cloud computing. If you look at the VMworld 2010 tracks and sessions this year, they focus on cloud computing. But you can’t have internal cloud computing without virtualization, so virtualization remains on the hot topics list, even if it’s no longer in the No. 1 spot.

In this tip, we consider how clouds and virtualization go hand in hand and how to leverage the capabilities of VMware vSphere to create your own private cloud.

Read the full article at searchvmware.com…

Share This:

Affordable shared storage options for VMware vSphere

You can use VMware vSphere without a shared storage device, but it limits the amount of advanced features that you can use with it. Certain features in vSphere require that a virtual machine (VM) reside on a shared storage device that is accessible by multiple hosts concurrently. These features include high availability (HA), Distributed Resource Scheduler (DRS), Fault Tolerance (FT) and VMotion, which provide high/continuous availability as well as workload load balancing and live migration of virtual machines. For some storage administrators, these features may only be nice to have, but they are also essential for many IT environments that cannot afford to have VMs down for an extended amount of time.

A few years ago, VMware shared storage typically meant using a Fibre Channel (FC) SAN, which was expensive, required specialized equipment and was complicated to manage. In recent years, other shared storage options that utilize standard network components to connect to storage devices have become popular and make for affordable, easy-to-use shared storage solutions. The protocols used for this are iSCSI and NFS, both of which are natively supported in vSphere. The performance of NFS and iSCSI are similar, but both can vary depending on a variety of factors including the data storage device characteristics, network speed/latency and host server resources. Since both protocols use software built into vSphere to manage the storage connections over the network there is some minimal CPU resource usage on the host server as a result.

Read the full article at searchsmbstorage.com…

Share This:

Using iSCSI storage with vSphere

To tap into some of VMware vSphere’s advanced features such as VMotion, fault tolerance, high availability and the VMware Distributed Resource Scheduler, you need to have shared storage for all of your hosts. vSphere’s proprietary VMFS file system uses a special locking mechanism to allow multiple hosts to connect to the same shared storage volumes and the virtual machines (VMs) on them. Traditionally, this meant you had to implement an expensive Fibre Channel SAN infrastructure, but iSCSI and NFS network storage are now more affordable alternatives.

Focusing on iSCSI, we’ll describe how to set it up and configure it properly for vSphere hosts, as well as provide some tips and best practices for using iSCSI storage with vSphere. In addition, we’ve included the results of a performance benchmarking test for the iSCSI/vSphere pairing, with performance comparisons of the various configurations.

Read the full article in the August 2010 issue of Storage Magazine at searchstorage.com…

cover_vol9_iss7

Share This:

Coverage

Social Media

VMworld on Twitter (Live TweetGrid)
Social Media at VMworld 2010
(VMworld blog)
Social Media Contributors at VMworld 2010 (VMworld wiki)
VMworld Contributor Twitter List (Twitter)
Official VMworld Twitter account (Twitter)
#vmworld Twitter hashtag search (Twitter)
VMworld Facebook page (Facebook)

Blogs

Planet V12n (Virtualization blog aggregator)
VMworld Team blog (VMworld website)
VMworld 2010 Buzz (VMworld aggregator)

Multimedia

VMworld TV channel (YouTube)
VMworld Videos (VMworld website)
VMworld Photos (VMworld website)

Podcasts

Share This:

Update on vSphere 4.1 power settings from my Tidbits post

I had a comment from a VMware engineer on my recent vSphere 4.1 Tidbits post that talked about the new power monitoring feature that clarified some things and I thought I would share it with everyone. There isn’t much documentation on this stuff yet so every little bit of information helps. From Tim Mann at VMware:

Let me clarify your paragraph on displaying host and VM power usage.  It muddles those two features together a bit.

(1) The feature of displaying the host power consumption is not
experimental and is always on, but will display 0 watts if the host
is not supported or does not have a power meter.  Hopefully most people
should not have to edit /usr/share/sensors/vmware to get support for
their host, but if you do, the instructions in the paragraph are OK.
Here are some more detailed instructions and additional lines that
are going into esx4.1u1:

#
# This file contains a list of power sensors that are known to VMware, Inc.
#
# OEMs: to add support for new machines, do not modify this file
# directly, but place a new file in this directory instead.
#
# Supported format:
#
#  EntryType:SensorType:Manufacturer:Product:Sensor1[,Sensor2…]:Units
#
# EntryType must be “default”, SensorType must be “power”, and Units
# must be “WATTS” (all without quotation marks).
#
# Manufacturer and Product are compared against the system’s DMI (also
# known as SMBIOS) information from its System Information (Type 1)
# record.  Manufacturer and Product are both case-insensitive and will
# match even if the actual name is longer; for example, “
Dell” would
# match “DELL, INC.”.  Product may be “*” to match all products from
# the specified Manufacturer.
#
# Sensor names are case-sensitive and must match exactly.  If multiple
# Sensors are listed on a line (up to 4), sensord reads them all, sums
# them, and reports the total as the system power.  It is acceptable
# for not all of the sensors listed on a line to be present; sensord
# will skip any that are missing as long as at least one is present.
#
default:power:FUJITSU:*:Pwr Mon:WATTS
default:power:FUJITSU:*:Total Power:WATTS
default:power:FUJITSU:*:SYSTEM:WATTS
default:power:FUJITSU:*:PSU1 Power,PSU2 Power:WATTS
default:power:Dell:*:System Level:WATTS
default:power:HP:*:Power Supply 1,Power Supply 2:WATTS
default:power:Hewlett-Packard:*:Power Meter:WATTS
default:power:Hewlett-Packard:*:Power Supply 1,Power Supply 2:WATTS
default:power:NEC:*:POWER:WATTS
default:power:NEC:*:Power:WATTS
default:power:NEC:*:Input_Power:WATTS
default:power:NEC:*:System Power:WATTS
default:power:MITSUBISHI:*:POWER:WATTS
default:power:MITSUBISHI:*:Power:WATTS
default:power:TOSHIBA:*:POWER:WATTS
default:power:TOSHIBA:*:Power:WATTS
default:power:BULL:*:POWER:WATTS

(2) The feature of displaying per-VM power consumption is experimental
and off by default.  It can be turned on with an advanced config option
as the paragraph describes.  The per-VM power consumption feature is
dependent on the host power consumption feature.

Share This: