Translate

Total Pageviews

My YouTube Channel

My YouTube Channel

Friday, 27 July 2012

Create a bootable VMware ESXi 5 USB stick in Windows and perform a scripted installation

Posted by at No comments:

Formatting a USB Flash Drive to Boot the ESXi 5.0 Installation or Upgrade

Details

You can format a USB flash drive to boot the ESXi 5.0 installation or upgrade.

Solution

This procedure requires the ESXi 5.0 ISO image VMware-VMvisor-Installer-5.0.0- XXXXXX.x86_64.iso, including the file isolinux.cfg,where XXXXXX is the build number of the installer ISO image. You can download the ESXi 5.0 ISO image from the VMware Web site.
 
These instructions assume that you are performing the procedure on a Linux machine and that the USB flash drive is detected as /dev/sdb.

Note: The ks file containing the installation script cannot be located on the same USB flash drive that you are using to boot the installation or upgrade.
  1. Attach the USB flash drive to a Linux machine. 
  2. Create a partition table.
    /sbin/fdisk /dev/sdb
    1. Type d to delete partitions until they are all deleted.
    2. Type n to create primary partition 1 that extends over the entire disk.
    3. Type t to set the type to an appropriate setting for the FAT32 file system, such as c.
    4. Type a to set the active flag on partition 1.
    5. Type p to print the partition table.
      The result should be similar to the following text:
      Disk /dev/sdb: 2004 MB, 2004877312 bytes
      255 heads, 63 sectors/track, 243 cylinders
      Units = cylinders of 16065 * 512 = 8225280 bytes
      Device    Boot  Start   End   Blocks    Id   System
      /dev/sdb1  *    1       243   1951866   c    W95 FAT32 (LBA)
    6. Type w to write the partition table and quit. 
  3. Format the USB flash drive with the Fat32 file system./sbin/mkfs.vfat -F 32 -n USB /dev/sdb1 
  4. Run the following commands./path_to_syslinux-3.86_directory/syslinux-3.86/bin/syslinux /dev/sdb1
    cat /path_to_syslinux-3.86_directory/syslinux-3.86/usr/share/syslinux/mbr.bin > /dev/sdb     
  5. Mount the USB flash drive.mount /dev/sdb1 /usbdisk 
  6. Mount the ESXi installer ISO image.mount -o loop VMware-VMvisor-Installer-5.0.0-XXXXXX.x86_64.iso /esxi_cdrom 
  7. Copy the contents of the ISO image to /usbdisk.
    cp -r /esxi_cdrom/* /usbdisk     
  8. Rename the isolinux.cfg file to syslinux.cfg.
    mv /usbdisk/isolinux.cfg /usbdisk/syslinux.cfg     
  9. In the file /usbdisk/syslinux.cfg, change the line APPEND -c boot.cfg  to APPEND -c boot.cfg -p 1. 
  10. Unmount the USB flash drive.umount /usbdisk 
  11. Unmount the installer ISO image.umount /esxi_cdrom 
The USB flash drive can now boot the ESXi installer.
Source of this Info:-
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2004510
Posted by at No comments:

Thursday, 26 July 2012

Advanced Configuration options for VMware High Availability

Purpose

In the majority of environments, VMware High Availability (HA) default settings do not need to be changed. However, depending on your specific environment you may need to modify some HA options. This article describes the different configuration options available and how to apply them.

Resolution


Note: Not all configuration variables work in all versions of VirtualCenter/vCenter Server. As new variables are introduced in newer releases, they remain throughout later versions.

Applying a VMware HA customization

To access the various customizations available:
  1. Login to vCenter Server with VMware Infrastructure/vSphere Client as an administrator.
  2. Right-click the Cluster in the Inventory and select Edit Settings.
  3. Click VMware HA.
  4. Click the Advanced Options button.
  5. Enter Option and Value fields as appropriate (see below).
  6. Click OK.
  7. Click OK again.
  8. Wait for the Reconfigure Cluster task to complete and then right-click the Cluster again from the Inventory.
  9. Click Properties.
  10. Disable VMware HA and wait for the Reconfiguration Cluster task(s) to complete.
  11. Right-click the cluster and Enable VMware HA to have the settings take effect.

VMware High Availability Advanced options

These settings are available in VirtualCenter 2.0.0 and above:
  • das.defaultfailoverhost = <hostname>This option/value pair is used to set a preferred failover host, where <hostname> represents the short name of the preferred host. The host specified is used as the first choice in case of a failure. However, if there is insufficient capacity VMware HA automatically selects an alternate host.
  • das.isolationaddress = <value>This option/value pair changes the default isolation address, where <value> represents the IP address that is to be used as the isolation address. By default the address used is the Default Gateway address for the ESX host because it is a highly available address. This address is queried as one of the items in determining if an isolation response has occurred on the host, thus if this parameter is changed be sure to use a reliable, highly available IP address with as few failure points between it and the ESX host as possible.
These settings are available in VirtualCenter 2.x and above:
  • das.failuredetectiontime = <value>This option/value pair changes the default failure detection timeout, where <value> represents the failure time in milliseconds. VMware HA uses this timeout in declaring an isolation response, and does not declare a host as isolated until this timeout has been reached without any heartbeats received. By default the default failure detection time is 15 seconds (15000 ms). However, another common alternative is 60 seconds (60000 ms).

    Note: das.failuredetectiontime is no longer supported in vCenter Server 5.x. 
  • das.usedefaultisolationaddress = <value> 

    This option/value pair disables the use of the default gateway as an isolation address, where <value> is either true or false. By default this value is set to true. This parameter is generally used in conjunction with thedas.isolationaddress1 to das.isolationaddress10 parameter(s) listed below.
  • das.isolationaddress1 to das.isolationaddress10 = <value>These option/value pair(s) specify more than one alternate isolation address for VMware HA to use, where<value> represents the IP address to be used for isolation detection. When using more than one isolation address it is recommended that the das.failuredetectiontime parameter be increased to ensure proper failover detection can occur. Also, although up to 10 different isolation addresses can be specified one or two addresses should be sufficient for proper failover detection. For more information on setting multiple isolation addresses, see Setting Multiple Isolation Response Addresses for VMware High Availability (1002117).

    Note: The     das.isolationaddress parameter is still supported if you are not using more than one alternative isolation address.
These settings are available in VirtualCenter 2.5.0 and above:
  • das.powerOffOnIsolation = <value>

    T    his option/value pair overrides the default isolation response setting to shutdown all the virtual machines when an isolation response occurs, where <value> is either true or false. By default this value is set to true. If changed to false all virtual machines will remain powered on in case of isolation.
  • das.vmMemoryMinMB = <value>

    T    his option/value pair overrides the default memory slot size value used for admission control for VMware HA, where <value> is the amount of RAM in MB to be used for the calculation if there are no larger memory reservations. By default this value is set to 256MB.
  • das.vmCpuMinMHz = <value>This option/value pair overrides the default CPU slot size value used for admission control for VMware HA, where<value> is the amount of CPU in MHz to be used for the calculation if there are no larger CPU reservations. By default this value is set to 256MHz.
These settings are available in VirtualCenter 2.5.0 Update 2 and above:
  • das.conservativeCpuSlot = <value>

    This option/value pair reverts how conservative VMware HA is in regards to vCPU when calculating slot size for admission control, where <value> represents either a value of true or false. By default in VirtualCenter 2.5.0 Update 2 this option is false to make the admission control less conservative. If set to true it reverts to the behavior of admission control as it was VirtualCenter 2.5.0, and VirtualCenter 2.5.0 Update 1.
  • das.allowvMotionNetworks = <value>

    This option/value pair allows vMotion networks to be considered for VMware HA usage, where <value> represents a value of true or false. This parameter enables a host that only has one Network card configured for management and vMotion combined to be properly configured for VMware HA. By default this value is false, and any vMotion network is ignored.
  • das.allowNetwork[...]

    This option enables the use of port group names to control the networks used for HA. You can set the value to be "Service Console 2" or "Management Network" to use those port group names in the networking configuration.
This setting is available in VirtualCenter 2.5.0 Update 3 and above:
  • das.ignoreRedundantNetWarning = <value>
    To suppress the message Host <xxx> currently has no management network redundancy, which appears if the Service Console does not have network redundancy configured properly on ESX hosts in the VMware High Availability (HA) cluster or if the warning appears for a host already configured in a cluster, set the VMware HA advanced option das.ignoreRedundantNetWarning to true and reconfigure VMware HA on that host. For further information, see KB 1004700.
This setting is available in vCenter Server 4.x and above:
  • das.slotmeminmb

    This option defines the maximum bound on the memory slot size. If this option is used, the slot size is the smaller of this value or the maximum memory reservation plus memory overhead of any powered-on virtual machine in the cluster. 
  • das.slotcpuinmhz

    This option defines the maximum bound on the memory slot size. If this option is used, the slot size is the smaller of this value or the maximum memory reservation plus memory overhead of any powered-on virtual machine in the cluster. 
These settings are available in vCenter Server 5.0
  • das.ignoreinsufficienthbdatastore 
Disables configuration issues created if the host does not have sufficient heartbeat datastores for vSphere HA. Default value is false.
  • das.heartbeatdsperhost 
Changes the number of heartbeat datastores required. Valid values can range from 2-5 and the default is 2.
Check this Link for more info:-
Posted by at No comments:

Monday, 23 July 2012

The Machine SID Duplication Myth (and Why Sysprep Matters)

Posted by at No comments:

Find Out Windows 7 / 2008 SID (Security Identifier)

Posted by at No comments:

Enhanced vMotion Compatibility (EVC) processor support

Details

Enhanced vMotion Compatibility (EVC) simplifies vMotion compatibility issues across CPU generations. EVC automatically configures server CPUs with Intel FlexMigration or AMD-V Extended Migration technologies to be compatible with older servers.
 
After EVC is enabled for a cluster in the VirtualCenter inventory, all hosts in that cluster are configured to present identical CPU features and ensure CPU compatibility for vMotion. The features presented by each host are determined by selecting a predefined EVC baseline. VirtualCenter does not permit the addition of hosts that cannot be automatically configured to be compatible with the EVC baseline.

Solution

To use EVC, you must be running ESX 3.5 Update 2 or higher with VirtualCenter 2.5 Update 2 or higher and have compatible processors in your servers. EVC does not allow for migration with VMotion between Intel and AMD processors.

Note: To search for supported EVC CPU types, see the charts below or refer to the WebHCL and search by EVC Modes.
 
Note the following restrictions:
  1. VMware cannot verify whether all processor models listed are capable of EVC support. For more information on supported servers and processors models, see the Systems Compatibility Guide for your ESX version.
  • Verify the BIOS settings for these processors enable Hardware Virtualization (if available) and Execute Protection. Default BIOS settings may not always enable these features. Hardware Virtualization is Intel VT on Intel processors and AMD-V on (supported) AMD processors. Execute Protection is Intel eXecute Disable (XD) on Intel processors and AMD No eXecute (NX) on AMD processors. For machines with AMD processors, under Processor Options, set No-Execute Page-Protection to Enabled. Until these CPU features are enabled, ESX hosts with EVC supported CPU types listed below will be unsupported.

    Note: XD is also listed as Execute Memory Protection under the processor option within the server BIOS.
    EVC capabilities of your server are based on two factors:
    1. The version of vCenter Server that manages the host.
    2. The underlying CPU architecture of the host processor.

      Tables 1.1 and 1.2 lists the available EVC baselines their description.      Table 2 describes EVC baselines supported by different vCenter Server versions.
      Tables 3.1 and 3.2 describe EVC baselines supported by different CPU architectures. 

    This section contains the following subjects:
    • Table 1.1: Description of Intel EVC Baselines
    • Table 1.2: Description of AMD EVC Baselines
    • Table 2: EVC Baselines supported in ESX releases
    • Table 3.1: EVC Baselines on Intel CPUs
    • Table 3.2: EVC Baselines on AMD CPUs
    • References 

    Table 1.1: Description of Intel EVC Baselines
    EVC BaselineDescription
    Intel®"Merom" Gen. (Intel® Xeon® Core™ 2)Applies baseline feature set of Intel® "Merom" Generation (Intel®Xeon® Core™2) processors to all hosts in the cluster.
    Intel® "Penryn" Gen. (Intel® Xeon® 45nm Core™ 2)Applies baseline feature set of Intel® "Penryn" Generation (Intel®Xeon® 45nm Core™2) processors to all hosts in the cluster.
    Compared to the Intel® "Merom" Generation EVC mode, this EVC mode exposes additional CPU features including SSE4.1
    Intel® "Nehalem" Gen. (Intel®Xeon® Core™ i7)Applies baseline feature set of Intel® "Nehalem" Generation (Intel® Xeon® Core™i7) processors to all hosts in the cluster.
    Compared to the Intel® "Penryn" Generation EVC mode, this EVC mode exposes additional CPU features including SSE4.2 and POPCOUNT
    Intel® "Westmere" Gen. (Intel®Xeon® 32nm Core™ i7)Applies baseline feature set of Intel® "Westmere" Generation (Intel® Xeon® 32nm Core™i7) processors to all hosts in the cluster. Compared to the Intel® "Nehalem" Generation mode, this EVC mode exposes additional CPU features including AES and PCLMULQDQ. 

    Note: Intel    ®i3/i5 Xeon®Clarkdale Series processors that do not support AESNI and PCLMULQDQ cannot be admitted to EVC modes higher than the Intel® "Nehalem" Generation mode. 
    Intel® "Sandy Bridge" Generation
    Applies baseline feature set of Intel® "Sandy Bridge" Generation processors to all hosts in the cluster. Compared to the Intel® "Westmere" Generation mode, this EVC mode exposes additional CPU features including AVX and XSAVE.
    Note: Intel® "Sandy Bridge" processors that do not support AESNI and PCLMULQDQ cannot be admitted to EVC modes higher than the Intel® "Nehalem" Generation mode.

    Table 1.2: Description of AMD EVC Baselines
    EVC BaselineDescription
    AMD Opteron™ Generation 1Applies baseline feature set of AMD Opteron™ Generation 1 (Rev. E) processors to all hosts in the cluster.
    AMD Opteron™ Generation 2Applies baseline feature set of AMD Opteron™ Generation 2 (Rev. F) processors to all hosts in the cluster.
    Compared to the AMD Opteron™ Generation 1 EVC mode, this EVC mode exposes additional CPU features including CPMXCHG16B and RDTSCP.
    AMD Opteron™ Generation 3Applies baseline feature set of AMD Opteron™ Generation 3 (Greyhound) processors to all hosts in the cluster.
    Compared to the AMD Opteron™ Generation 2 EVC mode, this EVC mode exposes additional CPU features including SSE4A, MisAlignSSE, POPCOUNT and ABM (LZCNT)
    AMD Opteron™ Generation 3 (no 3DNow!™ )Applies baseline feature set of AMD Opteron™ Generation 3 (Greyhound) processors, with 3DNow!™support removed, to all hosts in the cluster.

    This mode allows you to prepare clusters containing AMD hosts to accept AMD processors without 3DNow!    ™ support.
    AMD Opteron™ Generation 4
    Applies baseline feature set of AMD Opteron™ Generation 4 (Bulldozer) processors to all hosts in the cluster.
    Compared to the AMD Opteron™ Generation 3 (no 3DNow!™) EVC mode, this EVC mode exposes additional CPU features including SSSE3, SSE4.1, AES, AVX, XSAVE, XOP, and FMA4.

    Table 2 (part 1): EVC Baselines supported in vCenter Server releases
    EVC Cluster Baseline





    vCenter Server Release
    AMD Opteron™ Gen. 1
    AMD Opteron™ Gen. 2
    AMD Opteron™ Gen. 3
    AMD
    Opteron™
    Gen.
    3 
    (no 3DNow!    ™)
    AMD Opteron™ Gen. 4
    VirtualCenter 2.5 U2
    and later updates
    Yes
    No
    No
    No
    No
    vCenter Server 4.0
    Yes
    Yes
    Yes
    No
    No
    vCenter Server 4.0 U1
    and later updates
    Yes
    Yes
    Yes
    No
    No
    vCenter Server 4.1
    Yes
    Yes
    Yes
    Yes
    No
    vCenter Server 5.0
    Yes
    Yes
    Yes
    Yes
    Yes

    Table 2 (part 2): EVC Baselines supported in vCenter Server releases
    EVC Cluster Baseline





    vCenter Server Release
    Intel® "Merom" Generation
    Intel® "Penryn" Generation
    Intel® "Nehalem" Generation
    Intel® "Westmere" Generation
    Intel® "Sandy Bridge" Generation
    VirtualCenter 2.5 U2
    and later updates
    Yes
    No
    No
    No
    No
    vCenter Server 4.0
    Yes
    Yes
    Yes
    No
    No
    vCenter Server 4.0 U1
    and later updates
    Yes
    Yes
    Yes
    Yes
    No
    vCenter Server 4.1
    Yes
    Yes
    Yes
    Yes
    No
    vCenter Server 5.0
    Yes
    Yes
    Yes
    Yes
    Yes

    Table 3.1: EVC Baselines on Intel CPUs
    Note: In EVC clusters where the ESX host CPU model is Intel 3500 or 5500 series (Nehalem), ESX 3.5 Update 4 or later and VirtualCenter Server 2.5 Update 4 or later must be installed. For additional information, see VMotion fails with an RDTSCP error in EVC clusters where the ESX Host CPU Model is Intel 3500 series or 5500 series (Nehalem) (1011443). In EVC clusters where the ESX Host CPU model is Intel 3400 series, ESX 3.5 Update 5 or later and VirtualCenter Server 2.5 Update 5 or later must be installed. In EVC clusters where the ESX Host CPU model is Intel 7500 series, ESX 4.0 Update 1 or later and VirtualCenter Server 4.0 Update 1 or later must be installed.
    EVC Cluster Baseline





    Intel® Xeon®
    Host CPU Model
    Intel® "Merom"
    Generation
    Intel® "Penryn"
    Generation
    Intel® "Nehalem"
    Generation
    Intel® "Westmere"
    Generation
    Intel® "Sandy Bridge" Generation
    30xx Series
    Yes
    No
    No
    No
    No
    32xx Series
    Yes
    No
    No
    No
    No
    51xx Series
    Yes
    No
    No
    No
    No
    53xx Series
    Yes
    No
    No
    No
    No
    72xx Series
    Yes
    No
    No
    No
    No
    73xx Series
    Yes
    No
    No
    No
    No
    31xx Series
    Yes
    Yes
    No
    No
    No
    33xx Series
    Yes
    Yes
    No
    No
    No
    52xx Series
    Yes
    Yes
    No
    No
    No
    54xx Series
    Yes
    Yes
    No
    No
    No
    74xx Series
    Yes
    Yes
    No
    No
    No
    35xx Series
    Yes
    Yes
    Yes
    No
    No
    55xx Series
    Yes
    Yes
    Yes
    No
    No
    34xx Lynnfield Series
    Yes
    Yes
    Yes
    No
    No
    34xx Clarkdale Series 
    without AES and PCLMULQDQ
    Yes
    Yes
    Yes
    No
    No
    65xx Series
    Yes
    Yes
    Yes
    No
    No
    75xx Series
    Yes
    Yes
    Yes
    No
    No
    i3/i5 Clarkdale Series 
    without AES and PCLMULQDQ
    Yes
    Yes
    Yes
    No
    No
    34xx Clarkdale Series 
    with AES and PCLMULQDQ
    Yes
    Yes
    Yes
    Yes
    No
    28xx Series
    Yes
    Yes
    Yes
    Yes
    No
    36xx Series
    Yes
    Yes
    Yes
    Yes
    No
    48xx Series
    Yes
    Yes
    Yes
    Yes
    No
    56xx Series
    Yes
    Yes
    Yes
    Yes
    No
    88xx Series
    Yes
    Yes
    Yes
    Yes
    No
    i3/i5 Clarkdale Series 
    with AES and PCLMULQDQ
    Yes
    Yes
    Yes
    Yes
    No
    E7-28xx Series
    Yes
    Yes
    Yes
    Yes
    No
    E7-48xx Series
    Yes
    Yes
    Yes
    Yes
    No
    E7-88xx Series
    Yes
    Yes
    Yes
    Yes
    No
    E3-12xx Series
    Yes
    Yes
    Yes
    Yes
    Yes
    21xx Series
    Yes
    Yes
    Yes
    Yes
    Yes
    E5-26xx Series
    Yes
    Yes
    Yes
    Yes
    Yes
    Legend: CPU Architecture
    Intel® "Merom" (Core™2)
    Intel® "Penryn" (45nm Core™2)
    Intel® "Nehalem" (Core™ i7)
    Intel® "Westmere" (32nm Core™ i7)
    Intel® "Sandy Bridge"
    Notes:
  • Table 3.2: EVC Baselines on AMD CPUs

    EVC Cluster Baseline





    AMD Opteron™
    Host CPU Model
    AMD Opteron™
    Generation 1
    EVC Mode
    AMD Opteron™
    Generation 2
    EVC Mode
    AMD Opteron™
    Generation 3
    EVC Mode
    AMD Opteron™ 
    Generation 3
    (no 3DNow!™)
    EVC Mode
    AMD Opteron™
    Generation 4
    EVC Mode
    1xx Series
    Yes
    No
    No
    No
    No
    2xx Series
    Yes
    No
    No
    No
    No
    8xx Series
    Yes
    No
    No
    No
    No
    12xx Series
    Yes
    Yes
    No
    No
    No
    22xx Series
    Yes
    Yes
    No
    No
    No
    82xx Series
    Yes
    Yes
    No
    No
    No
    13xx Series
    Yes
    Yes
    Yes
    Yes
    No
    23xx Series
    Yes
    Yes
    Yes
    Yes
    No
    24xx Series
    Yes
    Yes
    Yes
    Yes
    No
    83xx Series
    Yes
    Yes
    Yes
    Yes
    No
    84xx Series
    Yes
    Yes
    Yes
    Yes
    No
    61xx Series
    Yes
    Yes
    Yes
    Yes
    No
    41xx Series
    Yes
    Yes
    Yes
    Yes
    No
    42xx Series
    No
    No
    No
    Yes
    Yes
    62xx Series
    No
    No
    No
    Yes
    Yes
    Legend: CPU Architecture
    AMD Opteron™ Generation 1 (Rev. E)
    AMD Opteron™ Generation 2 (Rev. F)
    AMD Opteron™ Generation 3 (Greyhound)
    AMD Opteron™ Generation 4 (Bulldozer)

Posted by at No comments:
Subscribe to: Posts (Atom)