VMware NSX Manager 6.0.5 install

1. General error when deploy NSX manager ova on vcenter 5.5 web client 

2.  Search the error and read some vcenter logs but didn't get any related error

3. Deploy use vSphere C# client is working:

Submarine Cable Map 2014

http://submarine-cable-map-2014.telegeography.com/

Vmware KB Testing VMkernel network connectivity with the vmkping command (1003728)

Testing VMkernel network connectivity with the vmkping command (1003728)

Purpose

For troubleshooting purposes, it may be necessary to test VMkernel network connectivity between ESX hosts in your environment.

This article provides you with the steps to perform a vmkping test between your ESX hosts.

Resolution

The vmkping command sources a ping from the local VMkernel port.

 

To initiate a vmkping test from the console of an ESX Server host:

1. Connect to the ESX/ESXi host using an SSH session. For information see Tech Support Mode for Emergency Support (1003677) andUsing Tech Support Mode in ESXi 4.1 and 5.0 (1017910).
   
2. In the command shell, run the command:
   
   # vmkping x.x.x.x
   where x.x.x.x is the hostname or IP address of the server that you want to ping.
   
3. If you have Jumbo Frames configured in your environment, run the vmkping command with the -s and -d options.
   
   # vmkping -d -s 8972 x.x.x.x
   Note: If you have more then one vmkernel port on the same network (such as a heartbeat vmkernel port for iSCSI) then all vmkernel ports on the host on the network would need to be configured with Jumbo Frames (MTU: 9000) too. If there are other vmkernel ports on the same network with a lower MTU then the vmkping command will fail with the -s 8972 option. Here in the command -d option sets DF (Don't Fragment) bit on the IPv4 packet.
   
   
4. In ESXi 5.1, you can specify which vmkernel port to use for outgoing ICMP traffic with the -I option:
   
   # vmkping -I vmkX x.x.x.x
   
   Notes: 
   
   • ICMP response behavior has changed in ESXi 5.1. For more information, see Change to ICMP ping response behavior in ESXi 5.1 (2042189).
   • In releases prior to ESXi 5.1, the host will automatically select the vmkernel port based on the host's vmkernel routing/forwarding table. To display the host's vmkernel routing table, use the esxcfg-route -l command.
   • Verification of your MTU size can be obtained from a SSH session by using

esxcfg-nics -l

Output should be similar to:

# esxcfg-nics -l

Name    PCI           Driver      Link Speed     Duplex MAC Address       MTU    Description

vmnic0  0000:02:00.00 e1000       Up   1000Mbps  Full   00:50:56:17:0a:60 9000   Intel Corporation 82545EM Gigabit Ethernet Controller (Copper)

vmnic1  0000:02:01.00 e1000       Up   1000Mbps  Full   00:50:56:17:0a:65 9000   Intel Corporation 82545EM Gigabit Ethernet Controller (Copper)

esxcfg-vmknic -l 

Output should be similar to:

# esxcfg-vmknic -l

Interface  Port Group/DVPort   IP Family IP Address                    Netmask         Broadcast   MAC Address          MTU     TSO     MSS       Enabled Type

vmk1       iSCSI  IPv4      10.10.10.10                                255.255.255.0   10.10.10.255 00:50:56:XX:XX:64    9000    65535     true    STATIC

A successful ping response is similar to:

 

# vmkping 10.0.0.1
PING server(10.0.0.1): 56 data bytes
64 bytes from 10.0.0.1: icmp_seq=0 ttl=64 time=10.245 ms
64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=0.935 ms
64 bytes from 10.0.0.1: icmp_seq=2 ttl=64 time=0.926 ms

--- server ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.926/4.035/10.245 ms

 

An unsuccessful ping response is similar to:

 

# vmkping 10.0.0.2
PING server (10.0.0.2) 56(84) bytes of data.

--- server ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 3017ms

 

Notes:

• If you see intermittent ping success, this might indicate you have incompatible NICs teamed on the VMotion port. Either team compatible NICs or set one of the NICs to standby.
• If you do not see a response when pinging by the hostname of the server, initiate a ping to the IP address. Initiating a ping to the IP address allows you to determine if the problem is a result of an issue with hostname resolution. If you are testing connectivity to another VMkernel port on another server remember to use the VMkernel port IP address because the server's hostname usually resolves to the service console address on the remote server.

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

networking device SIM note

For building a Lab consist of number of networks and cloud related products, i a am looking for some Router softwares which can connect different networks as the real router doing, There are some reference link below:

Cisco CSR1000v For Home Labs
http://www.fryguy.net/2013/12/27/cisco-csr1000v-for-home-labs/

Cisco CSR1000V vs the Fabled IOU
http://lamejournal.com/2013/12/28/cisco-csr1000v-vs-fabled-iou/

How to upgrade Titanium VMware image to 6.1.1

http://51sec.blogspot.hk/2013/03/how-to-upgrade-titanium-vmware-image-to.html

vSphere 5.5 Networking

Some useful points and to remind my self when deploy vsphere5.5 and configure network:

Networking Best Practices

Isolate from one another the networks for host management, vSphere vMotion, vSphere FT, and so on,

to improve security and performance.

Assign a group of virtual machines on a separate physical NIC. This separation allows for a portion of

the total networking workload to be shared evenly across multiple CPUs. The isolated virtual machines

can then better handle application traffic, for example, from a Web client.

To physically separate network services and to dedicate a particular set of NICs to a specific network

service, create a vSphere Standard Switch or vSphere Distributed Switch for each service. If this is not

possible, separate network services on a single switch by attaching them to port groups with different

VLAN IDs. In either case, verify with your network administrator that the networks or VLANs you

choose are isolated from the rest of your environment and that no routers connect them.

Keep the vSphere vMotion connection on a separate network. When migration with vMotion occurs,

the contents of the guest operating system’s memory is transmitted over the network. You can do this

either by using VLANs to segment a single physical network or by using separate physical networks

(the latter is preferable).

When using passthrough devices with a Linux kernel version 2.6.20 or earlier, avoid MSI and MSI-X

modes because these modes have significant performance impact.

You can add and remove network adapters from a standard or distributed switch without affecting the

virtual machines or the network service that is running behind that switch. If you remove all the

running hardware, the virtual machines can still communicate among themselves. If you leave one

network adapter intact, all the virtual machines can still connect with the physical network.

To protect your most sensitive virtual machines, deploy firewalls in virtual machines that route

between virtual networks with uplinks to physical networks and pure virtual networks with no

uplinks.

For best performance, use VMXNET 3 virtual machine NICs.

• E1000: An emulated version of the Intel 82545EM Gigabit Ethernet NIC. A driver for this NIC is not included with all guest operating systems. Typically Linux versions 2.4.19 and later, Windows XP Professional x64 Edition and later, and Windows Server 2003 (32-bit) and later include the E1000 driver.
  
  Note: E1000 does not support jumbo frames prior to ESXi/ESX 4.1.
• E1000e: This feature emulates a newer model of Intel Gigabit NIC (number 82574) in the virtual hardware. This is known as the "e1000e" vNIC. e1000e is available only on hardware version 8 (and newer) virtual machines in vSphere 5. It is the default vNIC for Windows 8 and newer (Windows) guest operating systems. For Linux guests, e1000e is not available from the UI (e1000, flexible vmxnet, enhanced vmxnet, and vmxnet3 are available for Linux).

• VMXNET 3: The VMXNET 3 adapter is the next generation of a paravirtualized NIC designed for performance, and is not related to VMXNET or VMXNET 2. It offers all the features available in VMXNET 2, and adds several new features like multiqueue support (also known as Receive Side Scaling in Windows), IPv6 offloads, and MSI/MSI-X interrupt delivery. For information about the performance of VMXNET 3, see Performance Evaluation of VMXNET3 Virtual Network Device. Because operating system vendors do not provide built-in drivers for this card, you must install VMware Tools to have a driver for the VMXNET 3 network adapter available.
  
  VMXNET 3 is supported only for virtual machines version 7 and later, with a limited set of guest operating systems:
  
  
  • 32- and 64-bit versions of Microsoft Windows 7, 8, XP, 2003, 2003 R2, 2008, 2008 R2, Server 2012 and Server 2012 R2
  • 32- and 64-bit versions of Red Hat Enterprise Linux 5.0 and later
  • 32- and 64-bit versions of SUSE Linux Enterprise Server 10 and later
  • 32- and 64-bit versions of Asianux 3 and later
  • 32- and 64-bit versions of Debian 4
  • 32- and 64-bit versions of Debian 5
  • 32- and 64-bit versions of Debian 6
  • 32- and 64-bit versions of Ubuntu 7.04 and later
  • 32- and 64-bit versions of Sun Solaris 10 and later
  
  Notes:
  
  • In ESXi/ESX 4.1 and earlier releases, jumbo frames are not supported in the Solaris Guest OS for VMXNET 2 and VMXNET 3. The feature is supported starting with ESXi 5.0 for VMXNET 3 only. For more information, see Enabling Jumbo Frames on the Solaris guest operating system (2012445).
  • Fault Tolerance is not supported on a virtual machine configured with a VMXNET 3 vNIC in vSphere 4.0, but is fully supported on vSphere 4.1.
  • Windows Server 2012 is supported with e1000, e1000e, and VMXNET 3 on ESXi 5.0 Update 1 or higher.

Physical network adapters connected to the same vSphere Standard Switch or vSphere Distributed

Switch should also be connected to the same physical network.

Configure all VMkernel network adapters in a vSphere Distributed Switch with the same MTU. When

several VMkernel network adapters, configured with different MTUs, are connected to vSphere

distributed switches, you might experience network connectivity problems.

When creating a distributed port group, do not use dynamic port binding. Dynamic port binding has

been deprecated since ESXi 5.0.

SR-IOV

Availability of Features

• The following features are not available for virtual machines configured with SR-IOV:
• vSphere vMotion
• Storage vMotion
• vShield
• NetFlow
• VXLAN Virtual Wire
• vSphere High Availability
• vSphere Fault Tolerance
• vSphere DRS
• vSphere DPM
• Virtual machine suspend and resume
• Virtual machine snapshots
• MAC-based VLAN for passthrough virtual functions
• Hot addition and removal of virtual devices, memory, and vCPU
• Participation in a cluster environment
• Network statistics for a virtual machine NIC using SR-IOV passthrough

Ref:

http://pubs.vmware.com/vsphere-55/topic/com.vmware.ICbase/PDF/vsphere-esxi-vcenter-server-55-networking-guide.pdf

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

Infiniband note ,lab and reference

have read the great article and experience sharing for an Infiniband Simple Lab architecture from Vladan's blog  here

some highlight for the article:

• implement 20GBs Infiniband (IB) connection with a little cost
• support Vsphere  5.x but need use non-official driver thus it should not be used in PROD environment.
•  It support windows server up to 2008R2 so cannot use the advanced features of  hyper-v 2012R2 server ><
• could test the RDMA Remote direct memory access performance
• difficult to scale out as you may need a expensive Infiniband switch 

ref:
Infiniband @ home: your homelab to 20Gbps   http://www.hypervisor.fr/?p=4662

Are InfiniBand's Days Numbered?

http://www.networkcomputing.com/storage/are-infinibands-days-numbered/a/d-id/1234663

Mellanox ConnectX-3-based InfiniBand and Ethernet Adapters for IBM System x

igure 2 shows the Mellanox ConnectX-3 40GbE / FDR IB VPI Adapter (the shipping adapter includes a heatsink over the ASIC but the figure does not show this heatsink)

Figure 2. Mellanox ConnectX-3 40GbE / FDR IB VPI Adapter for IBM System x with 3U bracket (required ASIC heatsink not shown)

Back to top

Features

The Mellanox Connect X-3 10GbE Adapter has the following features:

• Two 10 Gigabit Ethernet ports
• Low-profile form factor adapter with 2U bracket (3U bracket available for CTO orders)
• PCI Express 3.0 x8 host-interface (PCIe 2.0 and 1.1 compatible)
• SR-IOV (16 Virtual Functions) supported by KVM
• Enables Low Latency RDMA over Ethernet (supported with both non-virtualized and SR-IOV enabled virtualized servers)
• TCP/UDP/IP stateless offload in hardware
• Traffic steering across multiple cores
• Intelligent interrupt coalescence
• Industry-leading throughput and latency performance
• Software compatible with standard TCP/UDP/IP stacks
• Legacy and UEFI PXE network boot support

The Mellanox ConnectX-3 40GbE / FDR IB VPI Adapter has the following features:

• Dual QSFP ports supporting FDR-14 InfiniBand or 40 Gb Ethernet
• Low-profile form factor adapter with 2U bracket (3U bracket available for CTO orders)
• PCI Express 3.0 x8 host-interface (PCIe 2.0 and 1.1 compatible)
• Support for InfiniBand FDR speeds of up to 56 Gbps (auto-negotiation FDR-10, DDR and SDR)
• Support for Virtual Protocol Interconnect (VPI), which enables one adapter for both InfiniBand and 10/40 Gb Ethernet. Supports three configurations:
  • 2 ports InfiniBand
  • 2 ports Ethernet
  • 1 port InfiniBand and 1 port Ethernet
• SR-IOV (16 Virtual Functions) supported by KVM (Ethernet mode only)
• Enables Low Latency RDMA over 40Gb Ethernet (supported with both non-virtualized and SR-IOV enabled virtualed servers)
• High performance/low-latency networking
• Sub 1 µs InfiniBand MPI ping latency
• Support for QSFP to SFP+ for 10 GbE support
• Traffic steering across multiple cores
• Legacy and UEFI PXE network boot support (Ethernet mode only)

http://www.redbooks.ibm.com/redbooks.nsf/RedbookAbstracts/tips0897.html

4K Video Drives New Demands

http://www.mellanox.com/blog/2014/04/4k-video-drives-new-demands/

VMware Netorking KB

Point-to-Point Tunneling Protocol (PPTP) connections may not work on ESXi 5.5(2061834)

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

Symptoms

• After upgrading to ESXi 5.5, the virtual machine providing Virtual Private Network (VPN)/Router/Firewall services is unable to connect to via Point-to-Point Tunneling Protocol.
• The virtual machine providing VPN/Router/Firewall is configured to use an E1000 vNIC adapter.
• Clients are unable to establish a PPTP connection to the virtual machine.
• Attempts to connect to the virtual machine with:
  Error 628