Availability of vSphere Client for Linux systems

Purpose

This article provides information about the availability of the vSphere Client for Linux systems.

Resolution

The vSphere Client is only available for Windows systems and it is not available for Linux systems.

In vCenter Server 4.x, vSphere Web Access, a subset of vSphere Client functionality, can be used from Linux systems. For more information about vSphere Web Access, see the vSphere Web Access Administrator's Guide.

In vCenter Server 5.0, the vSphere Web Client can be used from Linux platforms as well. The vSphere Web Client includes a subset of the functions available in the vSphere Client.

This table provides a comparison of the two clients:

vSphere Client	vSphere Web Client
For infrastructure configuration and day-to-day operations	For day-to-day operations
Locally-installed application	Web application
Runs only on Windows	Cross-platform
Can connect to vCenter Server or directly to hosts	Can connect only to vCenter Server
Full range of administrative functionality	Subset of full functionality, focused on virtual machine deployment and basic monitoring functions. Cannot configure hosts, clusters, networks, datastores, or datastore clusters.
Users: Virtual infrastructure administrators for specialized functions	Users: Virtual infrastructure administrators, help desk, network operations center operators, virtual machine owners.

Source:-
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1006095

Disabling simultaneous write protection provided by VMFS using the multi-writer flag

Details

VMFS is a clustered file system that disables (by default) multiple virtual machines from opening and writing to the same virtual disk ( .vmdk file). This prevents more than one virtual machine from inadvertently accessing the same .vmdk file.

The multi-writer option allows VMFS-backed disks to be shared by multiple virtual machines. This option is used to support VMware fault tolerance, which allows a primary virtual machine and a standby virtual machine to simultaneously access a .vmdkfile.

It is possible to use this option to disable the protection for certain cluster-aware applications where the applications ensure that writes originating from two or more different VMs will not cause data loss. This document describes the steps that need to be taken to modify the flag for a virtual disk.

Caution: Be careful when you disable this protection. This change might cause data corruption in cases where the applications in the virtual machine do not maintain consistency in the writes performed to the shared disk.

Use cases:

• VMware FT relies on VMware vLockstep technology to establish and maintain an active secondary virtual machine that runs in virtual lockstep with the primary virtual machine. The secondary virtual machine resides on a different host and executes exactly the same sequence of virtual (guest) instructions as the primary virtual machine. The multi-writer flag is automatically enabled when you turn on FT in the vSphere Client.
  
• Third-party cluster-aware applications where the applications ensure that writes originating from two or more different VMs will not cause data loss. For this case, manually enable the multi-writer flag using the instructions in this article.

Limitations:

• When using the multi-writer mode, the virtual disk must be eager zeroed thick; it cannot be zeroed thick or thin provisioned. For more information, see A virtual machine fails to power on with the error: Thin/TBZ disks cannot be opened in multiwriter mode. VMware ESX cannot open the virtual disk for clustering. (1033570).
  
  Note: This does not conflict with VMware's recommendation to use eager zeroed thick virtual disks when deploying Oracle databases.
  
• Sharing is limited to eight ESX hosts.
  
• Linked clones and snapshots are not supported. Be aware that other vSphere activities utilize cloning and that  backup solutions leverage snapshotting via the vAPIs.

For more information, see Oracle on VMware vSphere Essential Database Deployment Tips.

Solution

Enabling Virtual Disk Sharing

To configure a shared virtual disk by setting the multi-writer flag:

 

d

1. Create a virtual disk to be shared using any acceptable approach. For example, through the vSphere Client:
   
   
   1. Create a new disk for a virtual machine on a VMFS data store:
      
      
      
   2. Select Support clustering features such as Fault Tolerance. This creates the new virtual disk in the required format, eager zeroed thick.
      
      
      
      Note: ESXi 5.0 provides Thick Provision Lazy Zeroed, Thick Provision Eager Zeroed, and Thin Provision options under Disk Provisioning. Be sure to select Thick Provision Eager Zeroed. Also, note that the documentation may refer to this as Flat pre-initialized.
      
      
   3. Choose the appropriate Virtual Device Node setting, such as SCSI (1:0). Make a note of it, as it is required later.
      
      
      
      Note: There are command-line alternatives to perform the previous operation, but this instruction is beyond the scope of this article.
      
2. Add the multi-writer flag to configure sharing. There are two ways to achieve this:
   
   Note: Do not change the SCSI Controller's SCSI Bus Sharing options. Keep the default selection, None.
   
   
   1. Power off the virtual machine and the . vmx file that defines the virtual machine. Add entries like this:
      
      scsiX:Y.sharing = "multi-writer"
      where X is the controller ID and Y is the disk ID on that controller. The setting screen of a virtual machine shows these values.
      
      
      
      Add this setting for each virtual disk that you want to share. For example, to share four disks, the configuration file entries look like this:
      
      scsi1:0.sharing = "multi-writer"
      scsi1:1.sharing = "multi-writer"
      scsi1:2.sharing = "multi-writer"
      scsi1:3.sharing = "multi-writer"
      Now save the .vmx file and power on the virtual machine.
      
   2. In the vSphere Client, go to Edit Settings > Options > Advanced > General > Configuration Parameters. Add rows for each of the shared disks and set their value to multi-writer.
      
      Example:
      
      
      
3. Add this disk to another virtual machine:
   
   
   1. In the vSphere Client inventory, right-click the virtual machine and click Edit Settings.
      
   2. Click the Hardware tab and click Add.
      
   3. Select Hard Disk and click Next.
      
   4. Select Use an Existing Virtual Disk.
      
      Note: You do not need to create a disk because the disk is already created.
      
4. Enable sharing on this virtual machine, using one of the approaches listed in step 2.

Source:-

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1034165

Overview of vNetwork Distributed Switch concepts

Purpose

There are two types of virtual switches in ESX/ESXi 4.x and ESXi 5.x, vNetwork Standard Switch and vNetwork Distributed Switch.

Only vSphere Enterprise Plus supports the vNetwork Distributed Switch. For more information, see the vSphere purchase options.

Resolution

vNetwork Standard Switch (vSwitch, vSS)

Like in VMware Infrastructure 3, the configuration of each vSwitch resides on the specific ESX/ESXi. The VI administrators have to manually maintain consistency of the vSwitch configuration across all ESX/ESXi hosts to ensure that they can perform operations such as VMotion.

vSwitch is configured on each ESX/ESXi host.

vNetwork Distributed Switch (dvSwitch, vDS)

The configuration of vDS is centralized to vCenter. The ESX/ESXi 4.xand ESXi 5.x hosts that belong to a dvSwitch do not need further configuration to be compliant.

Distributed Switches provide similar functionalities to vSwitches. dvPortgroups is a set of dvPorts. The vDS equivalent of portgroups is a set of ports in a vSwitch. Configuration is inherited from dvSwitch to dvPortgroup, like what happens for vSwitch/Portgroup.

Virtual machines, Service Console interface (vswif), and VMKernel interfaces can be connected to dvPortgroups just as like they could be connected to portgroups in vSwitches

Administrative rights are required to create the following virtual adapters on each ESX/ESXi host dvSwitch in vCenter:

• Service Console and VMKernel interfaces
• Physical NICs and their assignment to dvSwitch Uplink groups

For more information on configuring dvSwitch, see Configuring vNetwork Distributed Switch using vCenter (1010557).

Comparing vNetwork Standard Switch with vNetwork Distributed Switch

These features are available with both types of virtual switches:

• Can forward L2 frames
• Can segment traffic into VLANs
• Can use and understand 802.1q VLAN encapsulation
• Can have more than one uplink (NIC Teaming)
• Can have traffic shaping for the outbound (TX) traffic

These features are available only with Distributed Switch:

• Can shape inbound (RX) traffic
• Has a central unified management interface through vCenter
• Supports Private VLANs (PVLANs)
• Provides potential customisation of Data and Control Planes

vSphere 5.0 provides these improvements to Distributed Switch functionality:

• Increased visibility of inter-virtual-machine traffic through Netflow
• Improved monitoring through port mirroring (dvMirror)
• Support for LLDP (Link Layer Discovery Protocol), a vendor-neutral protocol.

For more information on these features, see the Advanced Networking section of the vSphere Networking guide.

 

Source:-

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1010555

Private VLAN (PVLAN) on vNetwork Distributed Switch - Concept Overview

Purpose

This article provides a concept overview of Private VLAN (PVLAN).

Resolution

 

The definition of Private VLAN is:

• Virtual LAN (VLAN) is a mechanism to divide a broadcast domain into several logical broadcast domains.
• Private VLAN is an extension to the VLAN standard, already available in several (most recent) physical switches. It adds a further segmentation of the logical broadcast domain, to create “Private” groups.
• Private means that the hosts in the same PVLAN are not able to be seen by the others, except the selected ones in the promiscuous PVLAN.
• Standard 802.1Q Tagging indicates there is no encapsulation of a PVLAN inside a VLAN, everything is done with one tag per packet.
• No Double Encapsulation indicates that the packets are tagged according to the switch port configuration (EST mode), or they arrive already tagged if the port is a trunk (VST mode).
• Switch software decides which ports to forward the frame, based on the tag and the PVLAN tables.

A Private VLAN is further divided into the groups:

• Primary PVLAN – The original VLAN that is being divided into smaller groups is called Primary, and all the secondary PVLANs exist only inside the primary.
  
• Secondary PVLANs – The secondary PVLANs exist only inside the primary. Each Secondary PVLAN has a specific VLAN ID associated to it, and each packet travelling through it is tagged with an ID as if it were a normal VLAN, and the physical switch associates the behavior (Isolated, Community or Promiscuous) depending on the VLAN ID found in each packet.
  
  Note: Depending upon the type of the groups involved, hosts are not able to communicate with each other, even if they belong to the same group.

Three types of Secondary PVLANs:

• Promiscuous – A node attached to a port in a promiscuous secondary PVLAN may send and receive packets to any node in any others secondary VLAN associated to the same primary. Routers are typically attached to promiscuous ports.
  
• Isolated – A node attached to a port in an isolated secondary PVLAN may only send to and receive packets from the promiscuous PVLAN.
  
• Community – A node attached to a port in a community secondary PVLAN may send to and receive packets from other ports in the same secondary PVLAN, as well as send to and receive packets from the promiscuous PVLAN.

Notes:

• Promiscuous PVLANs have the same VLAN ID both for Primary and Secondary VLAN.
• Community and Isolated PVLANs traffic travels tagged as the associated Secondary PVLAN.
• Traffic inside PVLANs is not encapsulated (no Secondary PVLAN encapsulated inside a Primary PVLAN Packet).
• Traffic between virtual machines on the same PVLAN but on different ESX hosts go through the Physical Switch. Therefore, the Physical Switch must be PVLAN aware and configured appropriately, to allow the secondary PVLANs to reach destination.
• Switches discover MAC addresses per VLAN. This can be a problem for PVLANs because each virtual machine appears to the physical switch to be in more than one VLAN, or at least, it appears that there is no reply to the request, because the reply travels back in a different VLAN. For this reason, it is a requirement that each physical switch, where ESX with PVLANs are connected, must be PVLAN aware.

Additional Information

For related information on PVLAN, see:

• Configuration of a Private VLAN (PVLAN) on a vNetwork Distributed Switch (1010703)
• RFC 5517 Cisco Systems' Private VLANs
• Catalyst 3750 Switch Software Configuration Guide
• ESX Configuration Guide

Source:-

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1010691

Choosing a port binding type

Details

When choosing a port binding type, consider how you want to connect your virtual machines and virtual network adapters to a vDS and how you intend to use your virtual machines. Port binding type, along with all other vDS and port group configuration, can be set only through vCenter Server.

Solution

Types of port binding

These three different types of port binding determine when ports in a port group are assigned to virtual machines:

• Static Binding
• Dynamic Binding
• Ephemeral Binding

Static binding

When you connect a virtual machine to a port group configured with static binding, a port is immediately assigned and reserved for it, guaranteeing connectivity at all times. The port is disconnected only when the virtual machine is removed from the port group. You can connect a virtual machine to a static-binding port group only through vCenter Server.

Note: Static binding is the default setting, recommended for general use.

Dynamic binding

In a port group configured with dynamic binding, a port is assigned to a virtual machine only when the virtual machine is powered on and its NIC is in a connected state. The port is disconnected when the virtual machine is powered off or the virtual machine's NIC is disconnected. Virtual machines connected to a port group configured with dynamic binding must be powered on and off through vCenter.

Dynamic binding can be used in environments where you have more virtual machines than available ports, but do not plan to have a greater number of virtual machines active than you have available ports. For example, if you have 300 virtual machines and 100 ports, but never have more than 90 virtual machines active at one time, dynamic binding would be appropriate for your port group.

Note: Dynamic binding is deprecated in ESXi 5.0.

Ephemeral binding

In a port group configured with ephemeral binding, a port is created and assigned to a virtual machine when the virtual machine is powered on and its NIC is in a connected state. The port is deleted when the virtual machine is powered off or the virtual machine's NIC is disconnected.

Ephemeral port assignments can be made through ESX/ESXi as well as vCenter, giving you the flexibility to manage virtual machine connections through the host when vCenter is down. Although only ephemeral binding allows you to modify virtual machine network connections when vCenter is down, network traffic is unaffected by vCenter failure regardless of port binding type.

Note: Ephemeral portgroups should be used only for recovery purposes when you want to provision ports directly on host bypassing vCenter Server, not for any other case. This is true for several reasons:

• Scalability
  
  An ESX/ESXi 4.x host can support up to 1016 ephemeral portgroups and an ESXi 5.x host can support up to 256 ephemeral portgroups. Since ephemeral portgroups are always pushed to hosts, this effectively is also the vCenter Server limit. For more information, see Configuration Maximums for VMware vSphere 5.0 and Configuration Maximums for VMware vSphere 4.1.
  
• Performance
  
  Every operation, including add-host and virtual machine power operation, is slower comparatively because ports are created/destroyed in the operation code path. Virtual machine operations are far more frequent than host-add or switch-operations, so ephemeral ports are more demanding in general.
  
• Non-persistent (that is, "ephemeral") ports
  
  Port-level permissions and controls are lost across power cycles, so no historical context is saved.

Note: In vSphere 5.0, a new advanced option called autoExpand has been introduced. This property of portgroups allows a portgroup to expand automatically by a small predefined margin whenever the portgroup is about to run out of ports.

This property is disabled by default, but it can be enabled using the vSphere 5.0 SDK via managed object browser:

1. In a browser, enter the address http://vc-ip-address/mob/.
2. When prompted, enter your vCenter Server username and password.
3. Click the Content link.
4. In the left pane, search for the row with the word rootFolder.
5. Open the link in the right pane of the row. The link should be similar to group-d1 (Datacenters).
6. In the left pane, search for the row with the word childEntity. In the right pane, you see a list of datacenter links.
7. Click the datacenter link in which the vDS is defined.
8. In the left pane, search for the row with the word networkFolder and open the link in the right pane. The link should be similar to group-n123 (network).
9. In the left pane, search for the row with the word childEntity. You see a list of vDS and distributed port group links in the right pane.
10. Click the distributed port group for which you want to change this property.
11. In the left pane, search for the row with the word config and click the link in the right pane.
12. In the left pane, search for the row with the word autoExpand. It is usually the first row.
13. Note the corresponding value displayed in the right pane. The value should be false by default.
14. In the left pane, search for the row with the word configVersion. The value should be 1 if it has not been modified.
15. Note the corresponding value displayed in the right pane as it is needed later.
16. Go back to the distributed port group page.
17. Click the link that reads ReconfigureDvs_Task. A new window appears.
18. In the Spec text field, enter this text:
    
    <spec><autoExpand>true</autoExpand><configversion>configVersion</configversion></spec>
    
    where configVersion is what you recorded in step 15.
19. Click the Invoke Method link.
20. Close the window.
21. Repeat Steps 10 through 14 to verify the new value for autoExpand.

These steps can be automated using a custom script. For more information, see the VMware vSphere blog entry Automating Auto Expand Configuration for a dvPortgroup in vSphere 5.

Examples: The script allows you to:

• Enable Auto Expand for a distributed portgroup, by running this command:
  
  updatedvPortgroupAutoExpand.pl --server vcenter-ip --username user --operation enable --dvportgroup portgroupname

• Disable Auto Expand for a distributed portgroup, by running this command:
  
  updatedvPortgroupAutoExpand.pl --server vcenter-ip --username user --operation disable --dvportgroup portgroupname

 

Source:-

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1022312

vMA5 and IP Allocation Policy

The vMA should now be deployed to your vSphere cluster and you will end up with a new VM in you inventory. But at this point you cannot power on the VM since there is no IP pool configured. If you try to boot the VM will you get an error message like this:

Cannot initialize property ‘vami.DNS0.vSphere_Management_Assistant_(vMA)’, since network ‘VM Network’ has no associated IP pool configuration.

To get the vMA started you have to disable the vApp Option check this Demo:

 

 

 

vMA5 Deployment Demo

vMA5 vi-admin Password Complexity Issue

In vMA5 you won't be able to set the password for the vi-admin unless and until your password is complex. I spent approx. 30 Minutes to assign the password to vi-admin account. Here is screenshoot of errors that i was getting at that time.

Then i configured Axtm123!# as the password then as soon as my vMA appliance was booted i logged in here by using vi-admin as the username and Axtm123!# as the password and this command is executed by me:
                                   sudo passwd vi-admin
then type old password that is Axtm123!#  and then new password vmware@123  is configured by me the only message is you will get it is based on the dictionary word but it will accept it. This is what the solution in my lab environment but try this only in your lab environment not in production environment.

Differences between QuickPrep and Sysprep

Purpose

This article discusses the main between VMware QuickPrep and Microsoft Sysprep. It further describes the functions of the two methods allowing users to select the appropriate method for creating Linked Clone Desktops.

Resolution

QuickPrep is a VMware system tool executed by View Composer during a linked-clone desktop deployment. QuickPrep personalizes each desktop created from the Master Image. Microsoft Sysprep is a tool to deploy the configured operating system installation from a base image. The desktop can then be customized based on an answer script. Sysprep can modify a larger number of configurable parameters than QuickPrep.

 

During the initial startup of each new desktop, QuickPrep:

• Creates a new computer account in Active Directory for each desktop.
• Gives the linked-clone desktop a new name.
• Joins the desktop to the appropriate domain.
• Optionally, mounts a new volume that contains the user profile information.

 

This table lists the main differences between QuickPrep and Sysprep:

Function	QuickPrep	Sysprep
Removing local accounts	No	Yes
Changing Security Identifiers (SID)	No	Yes
Removing parent from domain	No	Yes
Changing computer name	Yes	Yes
Joining the new instance to the domain	Yes	Yes
Generating new SID	No	Yes
Language, regional settings, date, and time customization	No	Yes
Number of reboots	0	1 (seal & mini-setup)
Requires configuration file and Sysprep	No	Yes

 

Note: A Guest Customization script is required in vCenter Server to use Sysprep. Sysprep is bundled in with Windows 7. For Windows XP, an appropriate Sysprep program needs to be installed on the vCenter Sever.

See Sysprep file locations and versions (1005593) for information on installing Sysprep tools.

 

For more information on the use of Sysprep and the Guest Customisation wizard,see Customizing Guest Operating Systems andInstalling the Microsoft Sysprep Tools in the vSphere Virtual Machine Administration Guide.

Source:-
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2003797