A network isolation address is an IP address that is pinged to determine if a host is isolated from the network. This address is pinged only when a host has stopped receiving heartbeats from all other hosts in the cluster. If a host can ping its network isolation address, the host is not network isolated, and the other hosts in the cluster have failed. However, if the host cannot ping its isolation address, it is likely that the host has become isolated from the network and no failover action is taken.
By default, the network isolation address is the default gateway for the host. There is only one default gateway specified, regardless of how many service console networks have been defined, so you should use the das.isolationaddress[...] advanced attribute to add isolation addresses for additional networks. For example, das.isolationAddress2 to add an isolation address for your second network, das.isolationAddress3 for the third, up to a maximum of das.isolationAddress9 for the ninth.
When you specify additional isolation address, VMware recommends that you increase the setting for the das.failuredetectiontime advanced attribute to 20000 milliseconds (20 seconds) or greater. A node that is isolated from the network needs time to release its virtual machine’s VMFS locks if the host isolation response is to fail over the virtual machines (not to leave them powered on.) This must happen before the other nodes declare the node as failed, so that they can power on the virtual machines, without getting an error that the virtual machines are still locked by the isolated node.
For more information on VMware HA advanced attributes, see “Customizing VMware HA Behavior,” on page 26.
das.isolationaddress
Sets the address to ping to determine if a host is isolated from the network. This address is pinged only when heartbeats are not received from any other host in the cluster. If not specified, the default gateway of the console network is used. This default gateway has to be a reliable address that is available, so that the host can determine if it is isolated from the network. You can specify multiple isolation addresses (up to 10) for the cluster: das.isolationaddressX, where X = 1-10. Typically you should specify one per service console. Specifying too many addresses makes isolation detection take too long and can affect VMware HA behavior.
das.usedefaultisolationaddress
By default, VMware HA uses the default gateway of the console network as an isolation address. This attribute specifies whether or not this default is used (true|false).
The SHA hash functions are a set of cryptographic hash functions designed by the National Security Agency (NSA) and published by the NIST as a U.S. Federal Information Processing Standard. SHA stands for Secure Hash Algorithm.
Vendors provide a sha-1 hash for software downloads. This enables you to verify that your downloaded files are unaltered from the original.
To confirm file integrity, use an sha-1 utility on your computer to calculate your own hash for files downloaded from the VMware web site.
If your calculated hash matches the message digest we provide, you are assured that the file was downloaded intact.
sha-1 utilities are available for Windows and Linux and Mac. Most UNIX installations provide a sha1sum command for sha-1 hashes. You may need a newer linux kernel to calculate the checksums for larger files.
The File Checksum Integrity Verifier (FCIV) can be used on Windows based products to verify sha-1 values. Please see http://support.microsoft.com/kb/841290 for details on FCIV.
Instructions on checking an sha-1 checksum on a Mac:
In Finder, browse to /Applications/Utilities.
Double-click on the Terminal icon. A Terminal window will appear.
In the Terminal window, type: “openssl sha1 ” (sha1 followed by a space).
Drag the downloaded file from the Finder into the Terminal window.
Click in the Terminal window, press the Return key, and compare the checksum displayed to the screen to the one on the vendor’s download page.
From TechNet
Windows Server 2008 R2 Standard, Enterprise, Datacenter, and Web (x64) – DVD (English)
File Name: en_windows_server_2008_r2_standard_enterprise_datacenter_web_x64_dvd_x15-50365.iso
Size: 2,858 (MB)
Date Published (UTC): 8/31/2009 10:22:24 AM
Last Updated (UTC): 1/11/2010 4:31:40 PM
SHA1: A548D6743129F2A02C907D2758773A1F6BB1BCD7
The following log files contain information that needs to be track on a VMware vSphere ESX 4 Classic Host to be in compliance with many security standards and best practices such as CIS Benchmark, PCI-DSS, SOX section 404, HIPPA, CPNI, COSO, ISO 20001, COBIT, and so on.
You can use syslog or splunk lightweight forwarders for this purpose.
/var/log/vmkernel
/var/log/secure
/var/log/vmkwarning
/var/log/vmksummary
/var/log/vmksummary.txt
/var/log/messages
/var/log/vmware/*.log
/var/log/vmware/aam/*.log
/var/log/vmware/aam/*.err
/var/log/vmware/webAccess/*.log
/var/log/vmware/vpx/vpxa.log
/vmfs/volumes/*/*/*.log
Table with Explanation of files to log for VMware vSphere ESX Classic version 4
Component
Location
Purpose
VMkernel
/var/log/vmkernel
Records activities related to the virtual machines and ESX
VMkernel warnings
/var/log/vmkwarning
Records activities with the virtual machines
VMkernel summary
/var/log/vmksummary
Used to determine uptime and availability statistics for ESX; comma separated
VMkernel summary human readable
/var/log/vmksummary.txt
Used to determine uptime and availability statistics for ESX; human‐readable summary
ESX host agent log
/var/log/vmware/hostd.log
Contains information on the agent that manages and configures the ESX host and its virtual machines
vCenter agent
/var/log/vmware/vpx/vpxa.log
Contains information on the agent that communicates with vCenter
Web access
Log all the files in the directory /var/log/vmware/webAccess/*.log
client.log, proxy.log, unitTest.log, viewhelper.log, objectMonitor.log, timer.log, updateThread.log
Records information on Web-based access to ESX
(service vmware-webAccess start on ESX host to enable this)
Authentication log
/var/log/secure
Contains records of connections that require authentication, such as VMware daemons and actions initiated by the xinetd.
Service Console
/var/log/messages
Contain all general log messages used to troubleshoot virtual machines or ESX
Virtual machines
The same directory as the affected virtual machine’s configuration files; named vmware.log and vmware‐*.log
/vmfs/volumes/<DS>/<VM>/vmware.log
/vmfs/volumes/<DS>/<VM>/vmware-*.log
Contain Virtual Machine Power Events, system crashes, Tools status and activity, Time Sync, Virtual Hardware changes, VMotion Migrations, Machine Clones,
VMware just updated their KB: Reserved or overhead ports for virtual switches (http://kb.vmware.com/kb/1008040) and we’ve run into this issue a number of times since upgrading to vSphere ESX 4. These new high memory hardware architectures allow an unprecedented number of virtual machine guests to be consolidated on a single ESX host.
By default a vswitch may not have enough ports to support the consolidation ratio your equipment can support. New ESX hosts can have 256 GB of RAM with 4 hex core processors and easily support 100 or more virtual machines. These virtual machines might have 1, 2, or more vNICs configured and each would need a port on the vswitch. One might imagine the need for 500 to 1000 ports needed per esx host. Why not just make it 2000 so we don’t have to worry about it later on?
Once you run out of vswitch ports you cannot power on any more vms on that host and even get errors about unplugged network cable. Increasing the vSwitch port allocation seems easy enough, vmotion all workload off the host, put it in maintenance mode, change the vswitch config, reboot. Some system administrators run into this issue and decide to make the number of ports allocated to the vswitch really high to prevent this from ever being an issue. This can cause problems though.
There’s a limit of how many vswitch ports in total an ESX host has to hand out to it’s various vswitches. In addition, if security is a concern, you may start running firewall virtual appliances like vShield Zones or Catbird. WAN Accerators and Performance Monitoring tools like AppSpeed also require additional vSwitches to be created. Ports used on these vSwitches all take away from the total bucket of available ports.
Once 4096 ports are allocated to existing vSwitches you will not be able to add additional hosts to a vNetwork Distributed Switch either.
We also have the following Security Recommendation:
Only allocate vswitch ports to virtual machines on demand and as needed.
This will make it difficult if not impossible to “plug” a VM into the wrong network by accident. Testing for this can be done manually through the vSphere Client. If there are no ports available on a vSwitch then this is a positive test.
1. While connected to the vCenter Server Navigate to Home – Inventory – Networking in the vSphere Client and click on the vDS in question.
2. Click on the Ports Tab
3. If all of the ports in the list have a VM associated with it in the “connected”column then this is a positive test.
Deployment scenarios where a very large number of uplinks are teamed together on a single virtual switch might significantly impact the number of ports on that virtual switch available for virtual machine use, and the overall size of the virtual switch might need to be adjusted accordingly.
The current port utilization data for virtual switches can be reviewed by using the esxcfg-vswitch –list command.
The current overhead utilization on a given virtual switch can be calculated by subtracting the Used Ports value for all PortGroups from the Used Ports value for that virtual switch.
Recommendation: Use VNDS vNetwork distributed Switches for all Virtual Machine traffic and limit the number of ports assigned to each standard vSwitch used for vmkernel and service console.
Standard vSwitch Procedure:
Note: A server reboot is required to apply the following configuration change. Migrate the virtual machines off the ESX host to prevent any downtime. On the vswitch there is an option to specify the number of ports the vswitch supports.
To view this setting:
Click the Configuration tab of the ESX host in the Virtual Infrastructure Client (VI Client).
Click Networking.
Click Properties.
Click on vSwitch.
Click Edit.
On the General tab select the number of ports you want and click OK.
The amazing Dudley Smith, from VMware’s Technical Account Manager team has release a larger version of his vSphere Network Connections and Ports for ESX diagram and an accompanying excel spreadsheet listing all the TCP/IP ports for various communication purposes.
HyTrust Appliance 2.0 is available. Building on the successes of 2009, which included our initial product launch and numerous awards, we’re happy to see the streak continue into 2010 by delivering a major new release that will empower enterprises to capitalize on the wave of datacenter virtualization and accelerate efforts to virtualize tier-one applications. The features available in HyTrust Appliance 2.0 deliver true enterprise-class policy management and access control capabilities to virtual infrastructure. New features include the following:
* Root Password Vault: Locks down privileged host accounts and provides passwords for temporary use to enable time-limited privileged account access. Root accounts on hypervisors are extremely powerful and, as a consequence, can create a significant liability if not kept out of the wrong hands. With the aid of Root Password Vault, all root account access is attributable to an individual and every action is logged, providing far greater visibility and accountability.
* Federated Deployment: Secure distributed system architecture allows for automated replication of policies and templates across multiple HyTrust Appliances as well as geographic boundaries. For larger enterprises with multiple datacenters and collocation facilities, Federated Deployment of HyTrust Appliances ensures consistency of controls across the entire infrastructure.
* Virtual Infrastructure Search: Enables quick and easy accessibility to all virtual infrastructure objects, policies, and logs within HyTrust Appliance.
* Remote API: Interface to remotely access and automate the administration of the HyTrust Appliance. Provides the greater scalability demanded by large, enterprise-wide deployments of virtualization.
* Object Policy Labels: Creates a policy categorization structure, similar to “Web 2.0 tagging” for virtual infrastructure objects, which enables better organization and tighter, more consistent controls. Object Policy Labels enable access, network segment, and zoning policies, which allows administrators to dictate which virtual machines are allowed to connect to which network segments or hosts via RuleSets and Constraints.
* Router-Mode: a deployment option where all VMware management traffic is forced to flow through the HyTrust Appliance. HyTrust Appliance acts as a router for the “protected” management subnet and ESX/ESXi hosts and vCenter Server use HyTrust Appliance as their default gateway. This adds yet another flexible deployment option to the other existing options, ensuring the HyTrust Appliance will easily adapt to any enterprise architecture.
Along with the new capabilities delivered in 2.0, we’d like to introduce you to the new editions of HyTrust Appliance:
* Community Edition is a free version of the product that supports up to three hosts.
* Standard Edition supports an unlimited number of hosts and offers more flexible deployment options.
* Enterprise Edition supports an unlimited number of hosts, offers more flexible deployment options, supports federation of multiple HyTrust Appliances, enables privileged account management via Root Password Vault, allows two-factor authentication, and offers a remote API for additional management flexibility.
- Protect your computer from viruses and malicious programs.