<==Charvo==> cloud age is upon Us

vSphere 5.5 vSphere 6.0 vSphere 6.5 Released date Sep-13  March 2015 Nov-16 Physical CPUs per host 320 480 576 Physical RAM per host 4 TB 12 TB 12 TB VMs per host 512 1024 1024 vCPU per VM 64 128 128 vRAM per VM 1 TB 4 TB 6 TB VMDK Size 62 TB 62 TB 62 TB Cluster Size 32 64 64 High Availability Reactive HA Reactive HA Proactive HA vSphere Integrated Containers  NO  NO YES VM Hardware Version 10 11 13 VMFS Version 5.6 5.61 6.81 Management vSphere Web Client (c#) vSphere Web Client (c#) vSphere Web Client -HTML 5 Client Authentication Management Single Sign-On 5.5 Platform Services Controller Platform Services Controller

First thing to do in a vSphere 6.x deployment is to understand the new deployment architecture options available on the vSphere 6.0 platform, which is somewhat different from the previous versions of vSphere. The below will highlight key information but is not a complete guide to all the changes..etc. For that I’d advise you to refer to the official vSphere documentation ( found here ) Deployment Architecture The deployment architecture for vSphere 6 is somewhat different from the legacy versions. I’m not going to document all of the architectural deference’s  (Please refer to the VMware product documentation for vSphere 6) but I will mention few of the key ones which I think are important, in a bullet point below. vCenter Server – Consist of 2 key components Platform Service Controller (PSC) PSC include the following components SSO vSphere Licensing Server VMCA – VMware Certificate Authority (a built in SSL certification authority to simply certificate provisioning to all

Introduction In a physical environment all the servers have dedicated physical NIC that are connected to a physical switch. VLANs in physical world are usually controlled by setting the VLAN ID on the physical switch port and then setting the server’s IP address to correspond to that NIC’s VLAN. But in a virtual environment, dedicating a physical NIC (pNIC) to each VM that resides on the host is not possible. In reality, a physical NIC of the Esxi host service many VMs, and these VM’s may need to be connected to different VLANs. So the method of setting a VLAN ID on the physical switch port doesn’t work. To counter this issue, 802.1Q VLAN tagging comes in picture in virtual environment. Before digging deep into 802.1Q VLAN tagging lets understand how networking works in a virtual environment. An Esxi host typically can have more than one physical network adapters for redundancy, load balancing and segregation. The physical NICs (pNICs) are connected to physical switches and

NIC Teaming In its simplest terms NIC teaming means that we are taking multiple physical NICs on a given ESXi host and combining them into a single logical link that provides bandwidth aggregation and redundancy to a vSwitch. NIC teaming can be used to distribute load among the available uplinks of the team.  A NIC teaming configuration can look like as shown in below screenshot: There are several Load Balancing policies available for the virtual switch. These are discussed as below: 1: Route Based on Originating virtual Port-ID : This is the default load balancing policy for a vSS or vDS. This policy doesn’t require any special configuration to be done at virtual switch level or physical switch level. In this policy when a NIC is added to a VM or a new VM is provisioned with a NIC and comes online, VMkernel assigns a Port-ID to the virtual NIC of the VM. The outgoing traffic from the VM NIC will be routed through which uplink (physical adapter) of the team is determine

To list open network ports and the processes that own them with netstat, you can use this command netstat -a You can add the -n option to netstat to get port numbers instead of having the utility try to provide names for services: netstat -an command-line tool to see what ports are in use, and use a special flag that tells us which port is assigned to each Windows process identifier number. Then we can use that number to look up exactly which process it is netstat -ab | more This will immediately show you a list, although it’s maybe a little complicated. You’ll see the process name in the list, and you can search for it. You can also use this other method, which takes an extra step, but makes it easier to locate the actual process: netstat -aon | more If you look on the right-hand side, you’ll see where I’ve highlighted the list of PIDs, or Process Identifiers. Find the one that’s bound to the port that you’re trying to troubleshoot—for this example, you’ll see that 0.