I decided to use Migration Assistant from Mac OS X El Captain to transfer files from Windows machine to new iMac 27.
It is a decent tool, and it provides option to migrate email, but I did not try that. I just used it to transfer my files, music, and video, etc. Of course, client tools need to be installed on Windows machine. Copy process took few hours over Wi-Fi.
Then I noticed that OS X actually created a new user account and copied all files I requested under that user! which is not exactly I wanted. I also observed by then, OS X createsits own Download, Pictures, Music, and movie folder outside Document folder, which is different from Windows by default. This is not quite convenient at all, and later I realized that it is for iTunes and Photos, and iBooks default file path.
OS X denies to move my previous windows files to my current folder, since they belongs to the migrated user, so I used cp -r to make a copy of the files, and then chown -R. One thing I ignore during this process is to keep to original timestamp. I am not exactly sure they are already lost during Migration Assistant process, and my cp -r process, since I deleted the migration assistant user account later before I realize this.
Migration Assistant doesn't provide option for web browser bookmarks, so I export my IE bookmarks and Firefox book marks, and import them back to Safari/Firefox.
OS X uses unicode for text file encoding (UTF 8/16), which is different from Windows text file by default. In order to open previous windows file via TextEdit, you need change it preference. To change it permanently for other application, command-line iconv or duplicate an open file in TextEdit , and the select unicode encoding for saving file.
iTunes could not play APE/FLAC files, so alternate application is VOX. VOX might not recognize cue file properly, so you need a UTF encoding version cue file via iconv or TextEdit.
iTunes can play MP3 files from my previous Windows machine, but I quickly noticed that MP3 tags are not displayed in iTunes Library. Again, it was due to encoding, as iTunes also use UTF, so a tag editor is required. eyeD3 is a command-line tool to do so, while Unicode Rewriter is a nicer application to do so too.
Before I changed MP3 file tag, I would like to know existing tag, Kid3 is the ideal application to do this.
I believe that Unicode Rewriter creates a new V2.3 MP3 tag with Unicode, after it reads original MP3 tag. Kid3 can be used to remove all unnecessary V1 tags and APE tags if any on MP3 files.
iTunes then can import unicode tagged MP3 file into iTune Library with proper display.
Audacity can modify sound file in various format
XLD can split APE files.
QuickPlayer might not be able to play certain video codec formats, so MPlayerX is the alternative to do so.
OS X creates default computer name during the first boot process, you can change afterward via command line scutil or from System Preference->Sharing. OS X has three related names, one of them is used for file sharing over the network.
Samba file sharing for ubuntu client doesn't work well, but afp does.
Samba file sharing for Windows client need profiled credential.
Shared folder on OS X is defined in Sharing section of System Preference.
Unarchiver can extract RAR file format
Didbit 1: screen capture: CMD+SHIFT+3 or CMD+SHIFT+4 partial screen (from Apple support)
Tidbit 2: CMD + <- beginning of line; CMD + -> end of line; CMD+ up beginning of page; CMD + down, end of page
Tidbit 3: Option + <-, forward one word;Option+->, backward one word; up and down for paragraph movement.
Tidbit 4: to delete after cursor: Fn + delete
Tidbit 5: to zoom screen: enable it from System Preference -> Accessibility -> Zoom
Sunday, October 30, 2016
UEFI PXE ESXi6 TFTP iPXE
Newer generation hardware default boot mode could be UEFI now, so existing PXE server might not work anymore.
VMware ESXi 6 ISO installation will still work for UEFI hardware, but there are changes for PXE boot process. Here is PDF link from VMware Installing VMware ESXi 6.0 Using PXE
Like always, my favorite blog site from William Lam already posted related blog a while ago about this:
http://www.virtuallyghetto.com/2015/10/support-for-uefi-pxe-boot-introduced-in-esxi-6-0.html
(Thank William again!)
VMware site PDF actually added obvious details which is missing from William: As we will use boot file from /efi/boot/bootx64.efi from installation ISO directly, instead of original pxelinux.0, so we need put boot.cfg file in the same location as mboot.efi. (bootx64.efi is renamed as mboot.efi), otherwise mboot.efi will not find boot.cfg during PXE boot process and throw out fatal TFTP error (15) about parsing boot.cfg.
VMware ESXi 6 ISO installation will still work for UEFI hardware, but there are changes for PXE boot process. Here is PDF link from VMware Installing VMware ESXi 6.0 Using PXE
Like always, my favorite blog site from William Lam already posted related blog a while ago about this:
http://www.virtuallyghetto.com/2015/10/support-for-uefi-pxe-boot-introduced-in-esxi-6-0.html
(Thank William again!)
VMware site PDF actually added obvious details which is missing from William: As we will use boot file from /efi/boot/bootx64.efi from installation ISO directly, instead of original pxelinux.0, so we need put boot.cfg file in the same location as mboot.efi. (bootx64.efi is renamed as mboot.efi), otherwise mboot.efi will not find boot.cfg during PXE boot process and throw out fatal TFTP error (15) about parsing boot.cfg.
Update: Later version of ESXi uses b.b00 as kernel in boot.cfg file, insead of tboot.
We might encounter TFTP error (24) during PXE boot process if we start PXE Boot with a web server
We might encounter TFTP error (24) during PXE boot process if we start PXE Boot with a web server
Update: mboot.efi doesn't have http capability for tftp to continue, so we need start iPXE first. iPXE can be obtained from ipxe.org, or just download package to from vCenter server Auto Deploy service. File name inside the package for iPXE is: snponly64.efi.
We don't have such issue for legacy BIOS, however now it is all about UEFI. If you decide to test out UEFI HTTP chainloading in VMWare VM, you need Burning iPXE into ROM for network adapter. (https://ipxe.org/howto/vmware)
The process is so-called chainload: snponly64.efi is obtained from tftp server, then it is look for mboot.efi from tftp server. Configuration in dhcpd.conf includes lines below:
class "pxeclients" {
match if substring(option vendor-class-identifier, 0, 9) = "PXEClient";
next-server ip-of-tftp-server;
if option client-system-arch = 00:07 or option client-system-arch = 00:09 {
if exists user-class and option user-class = "iPXE" {
# Instruct iPXE to load mboot.efi as secondary bootloader
filename = "mboot.efi";
} else {
# Load the snponly64.efi configuration of iPXE as initial bootloader
filename = "snponly64.efi";
}
} else {
filename "gpxelinux.0";
}
}
Tip 1: before you start UEFI PXE boot process, please check UEFI boot order, and make sure PXE is after hard disk, otherwise PXE boot process will repeat after ESXi server reboot :-) (If your ks.cfg file includes reboot after installation)
Tip 2: We use PXE boot for multiple ESXi servers installation purpose, so the easiest way I found out about assigning IP address as you expected via DHCP is to edit dhcpd.conf file for DHCP reservation:
group {
host host-name1 {hardware ethernet xx:xx:xx:xx:xx:xx; fixed-address ip-address1; option host-name "host-name1";
host host-name2 {hardware ethernet xx:xx:xx:xx:xx:xx; fixed-address ip-address2; option host-name "host-name2
...
}
Of course, you need reboot DHCP for this, but you don't need multiple MAC-address-boot.cfg files. dhcpd.conf syntax is really picky, so you will follow the format exactly
Tip 2: We use PXE boot for multiple ESXi servers installation purpose, so the easiest way I found out about assigning IP address as you expected via DHCP is to edit dhcpd.conf file for DHCP reservation:
group {
host host-name1 {hardware ethernet xx:xx:xx:xx:xx:xx; fixed-address ip-address1; option host-name "host-name1";
host host-name2 {hardware ethernet xx:xx:xx:xx:xx:xx; fixed-address ip-address2; option host-name "host-name2
...
}
Of course, you need reboot DHCP for this, but you don't need multiple MAC-address-boot.cfg files. dhcpd.conf syntax is really picky, so you will follow the format exactly
Saturday, October 13, 2012
IaaS PaaS SaaS
Infrastructure as a Service (IaaS)
Characteristics and components of IaaS include:
- Utility computing service and billing model.
- Automation of administrative tasks.
- Dynamic scaling.
- Desktop virtualization.
- Policy-based services.
- Internet connectivity.
Infrastructure as a Service is sometimes referred to as Hardware as a Service (HaaS).
Platform as a Service (PaaS) is a way to rent hardware, operating systems, storage and network capacity over the Internet. The service delivery model allows the customer to rent virtualized servers and associated services for running existing applications or developing and testing new ones.
Platform as a Service (PaaS) is an outgrowth of Software as a Service (SaaS), a software distribution model in which hosted software applications are made available to customers over the Internet. PaaS has several advantages for developers. With PaaS, operating system features can be changed and upgraded frequently. Geographically distributed development teams can work together on software development projects. Services can be obtained from diverse sources that cross international boundaries. Initial and ongoing costs can be reduced by the use of infrastructure services from a single vendor rather than maintaining multiple hardware facilities that often perform duplicate functions or suffer from incompatibility problems. Overall expenses can also be minimized by unification of programming development efforts.
On the downside, PaaS involves some risk of "lock-in" if offerings require proprietary service interfaces or development languages. Another potential pitfall is that the flexibility of offerings may not meet the needs of some users whose requirements rapidly evolve.
Software as a Service (SaaS) is a software distribution model in which applications are hosted by a vendor or service provider and made available to customers over a network, typically the Internet.
SaaS is becoming an increasingly prevalent delivery model as underlying technologies that support Web services and service-oriented architecture (SOA) mature and new developmental approaches, such as Ajax, become popular. Meanwhile, broadband service has become increasingly available to support user access from more areas around the world.
SaaS is closely related to the ASP (application service provider) and on demand computing software delivery models. IDC identifies two slightly different delivery models for SaaS. The hosted application management (hosted AM) model is similar to ASP: a provider hosts commercially available software for customers and delivers it over the Web. In the software on demand model, the provider gives customers network-based access to a single copy of an application created specifically for SaaS distribution.
Benefits of the SaaS model include:
- easier administration
- automatic updates and patch management
- compatibility: All users will have the same version of software.
- easier collaboration, for the same reason
- global accessibility.
What is XaaS (anything as a service)?
XaaS is a collective term said to stand for a number of things including "X as a service," "anything as a service" or "everything as a service." The acronym refers to an increasing number of services that are delivered over the Internet rather than provided locally or on-site. XaaS is the essence of cloud computing.
The most common examples of XaaS are Software as a Service (SaaS), Infrastructure as a Service (IaaS) and Platform as a Service (PaaS). The combined use of these three is sometimes referred to as the SPI model (SaaS, PaaS, IaaS). Other examples of XaaS include storage as a service (SaaS), communications as a service (CaaS), network as a service (NaaS) and monitoring as a service (MaaS).
Following the convention of pronouncing "SaaS" as "sass," "XaaS" is sometimes pronounced as "zass."
Thursday, April 12, 2012
Cisco Nexus 1000V
The Cisco Nexus 1000V is compatible with any upstream physical access layer switch that is Ethernet standard compliant, including the Catalyst 6500 series switch, Cisco Nexus switches, and switches from other network vendors. The Cisco Nexus 1000V is compatible with any server hardware listed in the VMware Hardware Compatibility List (HCL).
Cisco and VMware jointly designed APIs that produced the Cisco Nexus 1000V. The Cisco Nexus 1000V is a distributed virtual switch solution that is fully integrated within the VMware virtual infrastructure, including VMware vCenter for the virtualization administrator. This solution offloads the configuration of the virtual switch and port groups to the network administrator to enforce a consistent data center network policy.
The Cisco Nexus 1000V has the following components that can virtually emulate a 66-slot modular Ethernet switch with redundant supervisor functions:
• Virtual Ethernet module (VEM) data plane—Each hypervisor is embedded with one VEM, which is a lightweight software component that replaces the virtual switch by performing the following
functions:
– Advanced networking and security
– Switching between directly attached virtual machines
– Uplinking to the rest of the network
– Only one version of VEM can be installed on an ESX/ESXi host at any given time.
- Install VEM from host by esxupdate command or using VMware update manager (VUM)
• Virtual supervisor module (VSM) control plane—The VSM is a virtual appliance that can be
installed in either a standalone or active/standby HA pair. The VSM, with the VEMs that is controls,
performs the following functions for the Cisco Nexus 1000V system. (1.5GHz, 2GB memory, 3GB disk, 3vNics: Control, Management, Packet connection to vSwitch at ESX host)
– Configuration (domain ID, HA pair: Active/Standby, Admin password, hostid for registration and license; Trial license is valid for 16 CPUs for 60 days via TFTP installation)
– Management (register VSM plug-in to vSphere client, download the xml from Cisco)
– A single VSM can manage up to 64 VEMs.
– Monitoring (Port profile from Cisco is equal to Port Group for VMware)
– Diagnostics
– Integration with VMware vCenter
– Active-standby VSMs increase high availability
- vem status (check VEM state from host)
- add host to DVS from network view, matching uplink
- show module show the VEM/VSM installed and enabled from NX CLI
In the Cisco Nexus 1000V, traffic is switched between virtual machines locally at each VEM instance.
Each VEM also interconnects the local virtual machine with the rest of the network through the upstream
access-layer network switch (blade, top-of-rack, end-of-row, and so forth).
The VSM runs the control plane protocols and configures the state of each VEM accordingly, but it never forwards packets.
In the Cisco Nexus 1000V, the module slots are for the primary module 1 and secondary module 2. Either
module can act as active or standby. The first server or host is automatically assigned to Module 3. The
Network Interface Card (NIC) ports are 3/1 and 3/2 (vmnic0 and vmnic1 on the ESX/ESXi host). The
ports to which the virtual NIC interfaces connect are virtual ports on the Cisco Nexus 1000V where they
are assigned a global number.
Cisco and VMware jointly designed APIs that produced the Cisco Nexus 1000V. The Cisco Nexus 1000V is a distributed virtual switch solution that is fully integrated within the VMware virtual infrastructure, including VMware vCenter for the virtualization administrator. This solution offloads the configuration of the virtual switch and port groups to the network administrator to enforce a consistent data center network policy.
The Cisco Nexus 1000V has the following components that can virtually emulate a 66-slot modular Ethernet switch with redundant supervisor functions:
• Virtual Ethernet module (VEM) data plane—Each hypervisor is embedded with one VEM, which is a lightweight software component that replaces the virtual switch by performing the following
functions:
– Advanced networking and security
– Switching between directly attached virtual machines
– Uplinking to the rest of the network
– Only one version of VEM can be installed on an ESX/ESXi host at any given time.
- Install VEM from host by esxupdate command or using VMware update manager (VUM)
• Virtual supervisor module (VSM) control plane—The VSM is a virtual appliance that can be
installed in either a standalone or active/standby HA pair. The VSM, with the VEMs that is controls,
performs the following functions for the Cisco Nexus 1000V system. (1.5GHz, 2GB memory, 3GB disk, 3vNics: Control, Management, Packet connection to vSwitch at ESX host)
– Configuration (domain ID, HA pair: Active/Standby, Admin password, hostid for registration and license; Trial license is valid for 16 CPUs for 60 days via TFTP installation)
– Management (register VSM plug-in to vSphere client, download the xml from Cisco)
– A single VSM can manage up to 64 VEMs.
– Monitoring (Port profile from Cisco is equal to Port Group for VMware)
– Diagnostics
– Integration with VMware vCenter
– Active-standby VSMs increase high availability
- vem status (check VEM state from host)
- add host to DVS from network view, matching uplink
- show module show the VEM/VSM installed and enabled from NX CLI
In the Cisco Nexus 1000V, traffic is switched between virtual machines locally at each VEM instance.
Each VEM also interconnects the local virtual machine with the rest of the network through the upstream
access-layer network switch (blade, top-of-rack, end-of-row, and so forth).
The VSM runs the control plane protocols and configures the state of each VEM accordingly, but it never forwards packets.
In the Cisco Nexus 1000V, the module slots are for the primary module 1 and secondary module 2. Either
module can act as active or standby. The first server or host is automatically assigned to Module 3. The
Network Interface Card (NIC) ports are 3/1 and 3/2 (vmnic0 and vmnic1 on the ESX/ESXi host). The
ports to which the virtual NIC interfaces connect are virtual ports on the Cisco Nexus 1000V where they
are assigned a global number.
Memory Compression
ESX/ESXi provides a memory compression cache to improve virtual machine performance when you use memory overcommitment. Memory compression is enabled by default. When a host's memory becomes overcommitted, ESX/ESXi compresses virtual pages and stores them in memory.
Because accessing compressed memory is faster than accessing memory that is swapped to disk, memory compression in ESX/ESXi allows you to overcommit memory without significantly hindering performance. When a virtual page needs to be swapped, ESX/ESXi first attempts to compress the page. Pages that can be compressed to 2 KB or smaller are stored in the virtual machine's compression cache, increasing the capacity of the host.
You can set the maximum size for the compression cache and disable memory compression using the Advanced Settings dialog box in the vSphere Client.
Enable or Disable the Memory Compression Cache
Memory compression is enabled by default. You can use the Advanced Settings dialog box in the vSphere Client to enable or disable memory compression for a host.
Procedure
1 Select the host in the vSphere Client inventory panel and click the Configuration tab.
2 Under Software, select Advanced Settings.
3 In the left pane, select Mem and locate Mem.MemZipEnable.
4 Enter 1 to enable or enter 0 to disable the memory compression cache.
5 Click OK.
Set the Maximum Size of the Memory Compression Cache
You can set the maximum size of the memory compression cache for the host's virtual machines.
You set the size of the compression cache as a percentage of the memory size of the virtual machine. For example, if you enter 20 and a virtual machine's memory size is 1000 MB, ESX/ESXi can use up to 200MB of host memory to store the compressed pages of the virtual machine.
If you do not set the size of the compression cache, ESX/ESXi uses the default value of 10 percent.
Procedure
1 Select the host in the vSphere Client inventory panel and click the Configuration tab.
2 Under Software, select Advanced Settings.
3 In the left pane, select Mem and locate Mem.MemZipMaxPct.
The value of this attribute determines the maximum size of the compression cache for the virtual machine.
4 Enter the maximum size for the compression cache.
The value is a percentage of the size of the virtual machine and must be between 5 and 100 percent.
5 Click OK.
http://www.vmware.com/pdf/vsphere4/r41/vsp_41_resource_mgmt.pdf
Because accessing compressed memory is faster than accessing memory that is swapped to disk, memory compression in ESX/ESXi allows you to overcommit memory without significantly hindering performance. When a virtual page needs to be swapped, ESX/ESXi first attempts to compress the page. Pages that can be compressed to 2 KB or smaller are stored in the virtual machine's compression cache, increasing the capacity of the host.
You can set the maximum size for the compression cache and disable memory compression using the Advanced Settings dialog box in the vSphere Client.
Enable or Disable the Memory Compression Cache
Memory compression is enabled by default. You can use the Advanced Settings dialog box in the vSphere Client to enable or disable memory compression for a host.
Procedure
1 Select the host in the vSphere Client inventory panel and click the Configuration tab.
2 Under Software, select Advanced Settings.
3 In the left pane, select Mem and locate Mem.MemZipEnable.
4 Enter 1 to enable or enter 0 to disable the memory compression cache.
5 Click OK.
Set the Maximum Size of the Memory Compression Cache
You can set the maximum size of the memory compression cache for the host's virtual machines.
You set the size of the compression cache as a percentage of the memory size of the virtual machine. For example, if you enter 20 and a virtual machine's memory size is 1000 MB, ESX/ESXi can use up to 200MB of host memory to store the compressed pages of the virtual machine.
If you do not set the size of the compression cache, ESX/ESXi uses the default value of 10 percent.
Procedure
1 Select the host in the vSphere Client inventory panel and click the Configuration tab.
2 Under Software, select Advanced Settings.
3 In the left pane, select Mem and locate Mem.MemZipMaxPct.
The value of this attribute determines the maximum size of the compression cache for the virtual machine.
4 Enter the maximum size for the compression cache.
The value is a percentage of the size of the virtual machine and must be between 5 and 100 percent.
5 Click OK.
http://www.vmware.com/pdf/vsphere4/r41/vsp_41_resource_mgmt.pdf
iBFT iSCSI Boot Overview
ESXi hosts can boot from an iSCSI SAN using the software or dependent hardware iSCSI adapters and network adapters.
To deploy ESXi and boot from the iSCSI SAN, the host must have an iSCSI boot capable network adapter that supports the iSCSI Boot Firmware Table (iBFT) format. The iBFT is a method of communicating parameters about the iSCSI boot device to an operating system.
Before installing ESXi and booting from the iSCSI SAN, configure the networking and iSCSI boot parameters on the network adapter and enable the adapter for the iSCSI boot. Because configuring the network adapter is vendor specific, review your vendor documentation for instructions.
When you first boot from iSCSI, the iSCSI boot firmware on your system connects to an iSCSI target. If login is successful, the firmware saves the networking and iSCSI boot parameters in the iBFT and stores the table in the system's memory. The system uses this table to configure its own iSCSI connection and networking and to start up.
The following list describes the iBFT iSCSI boot sequence:
1 When restarted, the system BIOS detects the iSCSI boot firmware on the network adapter.
2 The iSCSI boot firmware uses the preconfigured boot parameters to connect with the specified iSCSI target.
3 If the connection to the iSCSI target is successful, the iSCSI boot firmware writes the networking and iSCSI boot parameters in to the iBFT and stores the table in the system memory.
NOTE The system uses this table to configure its own iSCSI connection and networking and to start up.
4 The BIOS boots the boot device.
5 The VMkernel starts loading and takes over the boot operation.
6 Using the boot parameters from the iBFT, the VMkernel connects to the iSCSI target.
7 After the iSCSI connection is established, the system boots.
iBFT iSCSI Boot Considerations
When you boot an ESXi host from iSCSI using iBFT-enabled network adapters, certain considerations apply.
The iBFT iSCSI boot does not support the following items:
* IPv6
* Failover for the iBFT-enabled network adapters
NOTE Update your NIC's boot code and iBFT firmware using vendor supplied tools before trying to install and boot VMware ESXi 4.1 release. Consult vendor documentation and VMware HCL guide for supported boot code and iBFT firmware versions for VMware ESXi 4.1 iBFT boot. The boot code and iBFT firmware released by vendors prior to the ESXi 4.1 release might not work.
After you set up your host to boot from iBFT iSCSI, the following restrictions apply:
* You cannot disable the software iSCSI adapter. If the iBFT configuration is present in the BIOS, the host re-enables the software iSCSI adapter during each reboot.
* You cannot remove the iBFT iSCSI boot target using the vSphere Client. The target appears on the list of adapter static targets
To deploy ESXi and boot from the iSCSI SAN, the host must have an iSCSI boot capable network adapter that supports the iSCSI Boot Firmware Table (iBFT) format. The iBFT is a method of communicating parameters about the iSCSI boot device to an operating system.
Before installing ESXi and booting from the iSCSI SAN, configure the networking and iSCSI boot parameters on the network adapter and enable the adapter for the iSCSI boot. Because configuring the network adapter is vendor specific, review your vendor documentation for instructions.
When you first boot from iSCSI, the iSCSI boot firmware on your system connects to an iSCSI target. If login is successful, the firmware saves the networking and iSCSI boot parameters in the iBFT and stores the table in the system's memory. The system uses this table to configure its own iSCSI connection and networking and to start up.
The following list describes the iBFT iSCSI boot sequence:
1 When restarted, the system BIOS detects the iSCSI boot firmware on the network adapter.
2 The iSCSI boot firmware uses the preconfigured boot parameters to connect with the specified iSCSI target.
3 If the connection to the iSCSI target is successful, the iSCSI boot firmware writes the networking and iSCSI boot parameters in to the iBFT and stores the table in the system memory.
NOTE The system uses this table to configure its own iSCSI connection and networking and to start up.
4 The BIOS boots the boot device.
5 The VMkernel starts loading and takes over the boot operation.
6 Using the boot parameters from the iBFT, the VMkernel connects to the iSCSI target.
7 After the iSCSI connection is established, the system boots.
iBFT iSCSI Boot Considerations
When you boot an ESXi host from iSCSI using iBFT-enabled network adapters, certain considerations apply.
The iBFT iSCSI boot does not support the following items:
* IPv6
* Failover for the iBFT-enabled network adapters
NOTE Update your NIC's boot code and iBFT firmware using vendor supplied tools before trying to install and boot VMware ESXi 4.1 release. Consult vendor documentation and VMware HCL guide for supported boot code and iBFT firmware versions for VMware ESXi 4.1 iBFT boot. The boot code and iBFT firmware released by vendors prior to the ESXi 4.1 release might not work.
After you set up your host to boot from iBFT iSCSI, the following restrictions apply:
* You cannot disable the software iSCSI adapter. If the iBFT configuration is present in the BIOS, the host re-enables the software iSCSI adapter during each reboot.
* You cannot remove the iBFT iSCSI boot target using the vSphere Client. The target appears on the list of adapter static targets
Load-Based Teaming (LBT)
vSphere 4.1 introduces a load-based teaming (LBT) policy that is traffic-load-aware and ensures physical NIC capacity in a NIC team is optimized. Note that LBT is supported only with the vNetwork Distributed Switch (vDS). LBT avoids the situation of other teaming policies where some of the distributed virtual uplinks (dvUplinks) in a DV Port Group's team are idle while others are completely saturated. LBT reshuffles the port binding dynamically, based on load and dvUplink usage, to make efficient use of the available bandwidth.
LBT is not the default teaming policy while creating a DV Port Group, so it is up to you to configure it as the active policy. As LBT moves flows among uplinks, it may occasionally cause reordering of packets at the receiver. LBT will only move a flow when the mean send or receive utilization on an uplink exceeds 75% of capacity over a 30 second period. LBT will not move flows any more often than once every 30 seconds.
vSphere 4 (and prior ESX releases) provide several load balancing choices, which base routing on the originating virtual port ID, an IP hash, or source MAC hash. While these load balancing choices work fine in the majority of virtual environments, they all share a few limitations. For instance, all these policies statically map the affiliations of the virtual NICs to the physical NICs (based on virtual switch port IDs or MAC addresses) and do not base their load balancing decisions on the current networking traffic and therefore may not effectively distribute traffic among the physical uplinks. Besides, none of these policies take into consideration the disparity of the physical NIC capacity (such as a mixture of 1 GbE and 10 GbE physical NICs in a NIC team).
Load-based teaming (LBT) is a dynamic and traffic-load-aware teaming policy that can ensure physical NIC capacity in a NIC team is optimized. In combination with VMware Network IO Control (NetIOC), LBT offers a powerful solution that will make your vSphere deployment even more suitable for your I/O-consolidated datacenter.
How LBT works :
LBT dynamically adjusts the mapping of virtual ports to physical NICs to best balance the network load entering or leaving the ESX/ESXi 4.1 host. When LBT detects an ingress- or egress- congestion condition on an uplink, signified by a mean utilization of 75% or more over a 30-second period, it will attempt to move one or more of the virtual ports to vmnic-mapped flows to lesser-used links within the team.
Subscribe to:
Posts (Atom)