What machines can you “not” Storage vMotion

VMware Storage VMotion is a component of VMware vSphere™that provides an intuitive interface for live migration of virtual machine disk files within and across storage arrays with no downtime or disruption in service. Storage VMotion relocates virtual machine disk files from one shared storage location to another shared storage location with zero downtime, continuous service availability and complete transaction integrity. StorageVMotion enables organizations to perform proactive storage migrations, simplify array migrations, improve virtual machine storage performance and free up valuable storage capacity.Storage VMotion is fully integrated with VMware vCenter Server to provide easy migration and monitoring.

How does it work

1. Before moving a virtual machines disk file, Storage VMotion moves the “home directory” of the virtual machine to the new location. The home directory contains meta data about the virtual machine (configuration, swap and log files).

2. After relocating the home directory, Storage VMotion copies the contents of the entire virtual machine storage disk file to the destination storage host, leveraging “changed block tracking” to maintain data integrity during the migration process.

3. Next, the software queries the changed block tracking module to determine what regions of the disk were written to during the first iteration, and then performs a second iteration of copy, where those regions that were changed during the first iteration copy (there can be several more iterations).

4. Once the process is complete, the virtual machine is quickly suspended and resumed so that it can begin using the virtual machine home directory and disk file on the destination datastore location.

5. Before VMware ESX allows the virtual machine to start running again, the final changed regions of the source disk are copied over to the destination and the source home and disks are removed.

What machines can you not Storage vMotion?

1. Virtual machines with snapshots cannot be migrated using Storage vMotion

2. Migration of virtual machines during VMware Tools installation is not supported

3. The host on which the virtual machine is running must have a license that includes Storage vMotion.

4. ESX/ESXi 3.5 hosts must be licensed and configured for vMotion. ESX/ESXi 4.0 and later hosts do not require vMotion configuration in order to perform migration with Storage vMotion.

5. The host on which the virtual machine is running must have access to both the source and target datastores

6. Virtual machine disks in non-persistent mode cannot be migrated

7. Clustered applications or clustered virtual machine configurations do not support Storage vMotion.

8. For vSphere 4.0 and higher, Virtual Disks and Virtual RDM pointer files can be relocated to a destination datastore, and can be converted to thick provisioned or thin provisioned disks during migration as long as the detsination is not an NFS Datastore

9. Physical Mode Pointer files can be relocated to the destination datastore but cannot be converted

vSphere 5 Licensing

This post has been written so I and others can start to understand vSphere licensing

Comparison of vSphere 5 Editions

VMware vSphere 5 licensing

vSphere 5 will be licensed on a per processor basis with a vRAM entitlement. Each vSphere 5 processor license will entitle the purchaser to a specific amount of vRAM, or memory configured to virtual machines. The vRAM entitlement can be pooled across a vSphere environment to enable a true cloud or utility-based IT consumption model. Just like VMware technology offers customers an evolutionary path from the traditional datacenter to a cloud infrastructure, the new vSphere 5 licensing model allows customers to evolve to a cloud-like “pay for consumption” model without disrupting established purchase, deployment, and license management practices and processes. Unlike vSphere 4.x licenses, vSphere 4.x licenses, vSphere 5 licenses do not impose any limits on the number of cores per processors and maximum size of RAM capacity per host

Licensing PDF

http://www.vmware.com/files/pdf/vsphere_pricing.pdf

A diagram showing licesning changes between vSphere 4.x and vSphere 5.x

Should vCenter and the vCenter DB be on the same subnet as the hosts

Because vSphere is not a single stand-alone server, application, or isolated computing system, the pieces of the puzzle will require some form of communication between them. There are many possible configuration scenarios depending on the environment in which vSphere is being deployed.

A vCenter Server must be able to communicate with each host and each vSphere client. Furthermore, if a remote database server is utilized rather than a local instance of the database, the required TCP/IP ports for that database installation are also required.

If an instance of vCenter Server is installed on Windows Server 2008, you must either disable the Windows Firewall or make an exception to allow communication between all of the required pieces of the environment.

vCenter Server requires several ports to be open when you select a default installation. Each of these ports will be used for a different portion of the overall communications path. To enable proper communication between each of the components, consult a network engineer to ensure the appropriate ports are open for communication.

Web ports that are required to be open include the following:

Port

 

Description

80

Required for the purpose of redirecting nonsecure requests to vCenter Server on a secure port

443

The default port used to communicate with vSphere Client and to look for data from vSphere Web Access Client and other VMware Software Development Kit (SDK) applications such as the VI Toolkit. You can change this port, but vSphere Client and any SDK applications must use the vCenter Server name, followed by the nondefault port number

8080

The port used by Web Services HTTP.

8443

The port used by Web Services HTTPS

389

The standard port number used for Lightweight Directory Access Protocol (LDAP) services. This port is used for the Directory Services component of vCenter Server. It must be available to vCenter Server, even if vCenter Server is not part of a Linked Mode Group. You can change from port 389 to any available port ranging from 1025 to 65535. This is the normal LDAP port that the vCenter Server Active Directory Application Mode (ADAM) instance listens on.

636

Used when using vCenter in Linked Mode. This is the Secure Sockets Layer (SSL) port of the local vCenter Server ADAM Instance. It is the preferred port number, but it can also be changed to any available port ranging from 1025 to 65535.

902

Used for multiple tasks. It is used to manage ESX and ESXi hosts and send data to them. vCenter Server also receives a heartbeat at regular intervals from hosts on port 902 over User Datagram Protocol (UDP). This port must not be blocked between vCenter Server and hosts, or between hosts. Port 902 is also used for providing remote console access to virtual machines from vSphere Client.

903

Used in the same fashion as 902: it provides remote console access of virtual machines to vSphere Client. These ports must be open for proper communication to occur between vCenter Server and vSphere Client, as well as from vSphere Client and the ESX and ESXi hosts

vCenter and the vCenter Database

If you want or need to have vCenter and the vCenter Database on separate VLAN’s, you only need to be sure you have enough network bandwidth and speed between them so that the VC performance will not be affected

A host interacts with the vCenter Server through two host management agents: hostd and vpxa. Hostd is started on the host during ESX boot up. It is primarily responsible for bookkeeping of the host-level entities like VMs, datastores, networks, and so on. It is also responsible for implementing the host-level functions of the vSphere Infrastructure API. The vCenter Server dispatches host-related operations to a host over the Web using a SOAP interface. On the host, another agent called vpxa listens to these SOAP requests and dispatches them to hostd using the vCenter Server API. When a host is added to a vCenter Server inventory, vpxa is installed and started on the host. The resource consumption of hostd and vpxa can be monitored using esxtop.
Because vCenter Server communicates with an ESX host through the vSphere Infrastructure API using a SOAP interface, one of the key contributors to the operational latencies is the number of network hops between vCenter Server and the ESX host. If the ESX host is located multiple network hops away from the vCenter Server, the operational latencies may increase significantly. It is therefore recommended that the ESX host resides as few network hops away from the vCenter Server and the DB as possible

VMware Compatibility Guide

VMware Compatibility Guide

The detailed lists show actual vendor devices that are either physically tested or are similar to the devices tested by VMware or VMware partners. VMware provides support only for the devices that are listed in this document

Benchmarking using Performance Tools

Depending on what application you’re trying to model in your VMware test lab, there are a variety of benchmarking tools you can use to stress-test your configuration. VMware provides an extensive benchmarking suite with its VMmark and View Planner offerings.

VMmark incorporates vMotion and Storage vMotion in addition to generating a simulated user workload. View Planner uses Microsoft Office, Adobe Reader and other applications to emulate a typical user workload in a virtual desktop infrastructure, allowing you to measure application delay and user experience on numerous VMs simultaneously.

There are several other load generators available, and with the exception of the SPEC and VMware View Planner benchmarks, you can download them all for free.

File Server Capacity Tool (FSCT): This Microsoft utility drives a load on a traditional CIFS/SMB/SMB2 file server and measures the highest throughput that a server (physical or virtual) can sustain.

Exchange Load Generator 2010 (LoadGen): This Microsoft utility simulates a variety of Exchange email clients at various load levels to help you size your servers before deployment.

Exchange Server Jetstress 2010: This Microsoft utility focuses on the back-end input/output subsystem of the Exchange environment.

Dell DVD Store Database Test Suite: Also part of VMmark, this test suite simulates typical ecommerce site transactions, with built-in load generation.

ESX, ESXi and VM Log Locations

Logs can help you find out what happened if commands do not have the desired results. On ESXi 5.0 systems, find all logs in the /var/log directory. Some of the items in that directory are symbolic links from the /var/run/log directory.

On ESXi 4.1 systems, you can find the following logs.

Location of Log Files for VMware Products

http://kb.vmware.com/selfservice/documentLinkInt.do?micrositeID=&popup=true&languageId=&externalID=1021806

Host and VM Log Locations

Location

Component

 

/var/log/vmware/vmware-serverd.log ESX Server 2.x service log
var/log/vmware/hostd.log Host management service logs, including virtual machine and host Tasks and Events, communication with the vSphere Client and vCenter Server vpxa agent, and SDK connections.
/var/log/vmware/vpx/vpxa.log vSphere client agent log
After you reboot your machine, files /root/vmkernel-log.<date> and /root/vmkernel-core.<date> are present. Virtual machine kernel core file
/var/log/messages Messages from the Service Console Linux kernel, including service startup and shutdown.
/var/log/vmksummary Summary of ESX host startup and shutdown, and an hourly heartbeat with uptime, number of virtual machines running, and service console resource consumption
/var/log/vmkernel VMkernel messages, alerts, and availability report, Core VMkernel logs, including device discovery, storage and networking device and driver events, and virtual machine startup.
/var/log/vmkwarning Summary of Warning and Alert log messages excerpted from the VMkernel logs.
vmware.logIn the same directory as the VMX file for the virtual machine Virtual machine log file
/.vmx Located on a datastore associated with the managed host. Use the virtual machine summary page in the vSphere Client to determine the datastore on which this file is located. Virtual machine configuration file
var/log/boot-logs/sysboot.log Early VMkernel startup, module loading, and host initialization.
/var/log/vmkiscsid.log Software iSCSI Client logs.

vCenter Log Locations

/var/log/vmware/vpx/vpxa.log vCenter Server vpxa agent logs, including communication with vCenter Server and the Host Management hostd agent.
/var/log/vmware/fdm/* VMware High Availability Logs for vCenter Server 5
/var/log/vmware/aam/* VMware High Availability Logs for vCenter Server 4

VMware vCLI for vSphere 5

VMware vCLI Instructions

The vSphere Command-Line Interface (vSphere CLI) command set allows you to run common system administration commands against ESX/ESXi systems from any machine with network access to those systems. You can also run most vSphere CLI commands against a vCenter Server system and target any ESX/ESXi system that vCenter Server system manages. vSphere CLI includes the ESXCLI command set, vicfg- commands, and some other commands.

  • Download and Install vCLI
  • http://www.vmware.com/support/developer/vcli/
  • Right click on the vCLI icon and select Run as Administrator
  • Navigate to c:\Program Files (x86)\VMware\VMware vSphere CLI\bin
  • You will see the below vCLI commands (Note the .pl extension on the end)

vcli2

  • An example of running a command would be as per below with vifs.pl
  • Type vifs.pl –help to see the associated switches for this command

vifs

  • Try typing vifs.pl –server esxihostserver –listdc

vifs3

  • Another example of this command as per below screenprints shows how you can create a folder on a Datstore
  • vifs.pl –server esxiserver –mkdir “[Datastore] test”

vifs4

Documentation

vSphere Command-Line Interface Documentation

Getting Started with vSphere Command-Line Interfaces

vSphere Command‐Line Interface Concepts and Examples

vSphere Command‐Line Interface Reference

YouTube Video

You Tube Video

Running Commands on Windows.

In order to stop having to put in credentials everytime you run a command you can can the following

save_session.pl –server esxiserver01 –username usera –password passswordxyz –savesessionfile c:\temp\vclisessionfile

The next time you run a command you can type the following

esxcli –server MyESXiHost –sessionfile c:\temp\vclisessionfile storage core filesystem list

vCLI Poster

http://blogs.vmware.com/tp/files/vmware-management-with-vcli-5.0.pdf

VMware Visio Action Pack

Overview

http://xtravirt.com/visio-action-pack-re-released-free-member-download

This excellent Visio icon pack for VMware & virtualization has been re-released as a free member download. It contains over 70 unique icons together with a user guide and sample diagram templates.

It is designed for Windows Operating Systems and has been designed to run on Microsoft Visio 2003 and Microsoft Visio 2007, although also runs on Mac Omnigraffle. They are not compatible with Microsoft Visio 2000 or 2002

vSphere 4 Client RDP Plug-in

There is a really useful and informative website called http://xtravirt.com which provides lots of free tools for virtualisation admins, one of these being the RDP Plugin which allows you to right click on any VM and Remote Desktop to this machine from the vClient

The Xtravirt vSphere RDP Plug-in provides integration of the Windows Remote Desktop tool with the VMware vSphere Client.

Utilising Remote Desktop to connect virtual machines provides a better user experience compared to the built-in VMware console as well as performing better across WAN connection

System Requirements

1. VMware vCenter Server version 4

2. Version 4.0 of the VMware vSphere Client

3. Microsoft .NET Framework 3.5

4. Version 7.0 or greater of the Microsoft Remote Desktop Connection client

Download File Contents

1. vSphere RDP Plug-in installation software

2. Install and User Guide

Screenprints

 

Port Group Security

Security Options

portsecurity

Promiscuous Mode

Promiscuous mode eliminates any reception filtering that the virtual network adapter would perform so that the guest operating system receives all traffic observed on the wire. By default, the virtual network adapter cannot operate in promiscuous mode.

Although promiscuous mode can be useful for tracking network activity, it is an insecure mode of operation, because any adapter in promiscuous mode has access to the packets regardless of whether some of the packets are received only by a particular network adapter. This means that an administrator or root user within a virtual machine can potentially view traffic destined for other guest or host operating system

Note

In some situations, you might have a legitimate reason to configure a standard switch to operate in promiscuous mode (for example, if you are running network intrusion detection software or a packet sniffer

MAC Address Changes

The setting for the MAC Address Changes option affects traffic that a virtual machine receives.

When the option is set to Accept, ESXi accepts requests to change the effective MAC address to other than the initial MAC address.

When the option is set to Reject, ESXi does not honor requests to change the effective MAC address to anything other than the initial MAC address, which protects the host against MAC impersonation. The port that the virtual adapter used to send the request is disabled and the virtual adapter does not receive any more frames until it changes the effective MAC address to match the initial MAC address. The guest operating system does not detect that the MAC address change was not honored.

Note

The iSCSI initiator relies on being able to get MAC address changes from certain types of storage. If you are using ESXi iSCSI and have iSCSI storage, set the MAC Address Changes option to Accept.

In some situations, you might have a legitimate need for more than one adapter to have the same MAC address on a network—for example, if you are using Microsoft Network Load Balancing in unicast mode. When Microsoft Network Load Balancing is used in the standard multicast mode, adapters do not share MAC addresses.

MAC address changes settings affect traffic leaving a virtual machine. MAC address changes will occur if the sender is permitted to make them, even if standard switches or a receiving virtual machine does not permit MAC address chan

Forged Transmits

The setting for the Forged Transmits option affects traffic that is transmitted from a virtual machine.

When the option is set to Accept, ESXi does not compare source and effective MAC addresses.

To protect against MAC impersonation, you can set this option to Reject. If you do, the host compares the source MAC address being transmitted by the operating system with the effective MAC address for its adapter to see if they match. If the addresses do not match, ESXi drops the packet.

The guest operating system does not detect that its virtual network adapter cannot send packets by using the impersonated MAC address. The ESXi host intercepts any packets with impersonated addresses before they are delivered, and the guest operating system might assume that the packets are dropped

Note

This option is enabled by default, because it is occasionally needed to avoid software licensing problems. For example, if software on a physical machine is licensed to a specific MAC address, it will not work in a virtual machine because the VM’s MAC address is different. In this case, allowing forged transmits enables you to use the software by forging the VM’s MAC address.

However, allowing forged transmits poses a security risk.If an administrator has only authorized specific MAC addresses to enter the network, an intruder may be able to change his unauthorized MAC address to an authorized one