RENAMING A WINDOWS DOMAIN WITH RENDOM

http://www.bauer-power.net/2011/05/renaming-windows-domain-with-rendom.html

vSphere object migration within vROPS

https://kb.vmware.com/kb/2136216

NSX multiple VTEPs load balancing

From: Kevin Barrass <kbarrass@vmware.com>

Date: Mittwoch, 24. Februar 2016 10:31

To: Yves Fauser <yfauser@vmware.com>, David Pasek <dpasek@vmware.com>, Emanuele Mazza <emazza@vmware.com>, Dimitri Desmidt <ddesmidt@vmware.com>

Subject: Re: NSX Question

Hi Yves, David.

Short answer is yes VM’s on the same logical switch on a host with two VTEP’s will most likely be balanced across those two VTEPs. Longer answer below :)

When you configure load balance SRCID or SRC MAC. We map dvPorts VM’s are attached to by either dvPort ID or MAC address of VM to one of the dvUplinks on the dvSwitch.

We also statically map each VTEP vmkernel interface to a dvUplink on the dvSwitch. This results in an approximate even split of VM’s across both uplinks.

Each VM will then be encapsulated in VXLAN by the IOChain of the dvUplink the VM is mapped to, the SRC IP of that encapsulation will be the VTEP vmkernel IP address that is mapped to the same dvUplink.

The Local Control Plane (netcpa) will report up to the central control plane this VM dvPort (MAC address) to VTEP mapping.

If a dvUplink on the dvSwitch should fail, all VM’s that were mapped to that dvUplink and the associated VTEP vmkernel interface will be re-mapped to one of the remaining dvUplinks. Also the Local Control Plane agent will report this re-mapping up to the central control plane.

You can view this mapping on the ESXi dataplane from using either esxtop or esxcli as well as on the central control plane as below,:

ESXTOP

 9:12:12am up 13 days 17:46, 492 worlds, 3 VMs, 4 vCPUs; CPU load average: 0.03, 0.03, 0.03

   PORT-ID              USED-BY  TEAM-PNIC DNAME              PKTTX/s  MbTX/s    PKTRX/s  MbRX/s %DRPTX %DRPRX 

  33554433           Management        n/a vSwitch0              0.00    0.00       0.00    0.00   0.00   0.00 

  33554434               vmnic0          - vSwitch0             76.29    0.19      53.41    0.06   0.00   0.00 

  33554435     Shadow of vmnic0        n/a vSwitch0              0.00    0.00       0.00    0.00   0.00   0.00 

  33554436                 vmk0     vmnic0 vSwitch0             76.29    0.19       0.00    0.00   0.00   0.00 

  50331649           Management        n/a DvsPortset-0          0.00    0.00       0.00    0.00   0.00   0.00 

  50331650               vmnic3          - DvsPortset-0          0.00    0.00       0.00    0.00   0.00   0.00 

  50331651     Shadow of vmnic3        n/a DvsPortset-0          0.00    0.00       0.00    0.00   0.00   0.00 

  50331652               vmnic2          - DvsPortset-0          0.00    0.00       0.00    0.00   0.00   0.00 

  50331653     Shadow of vmnic2        n/a DvsPortset-0          0.00    0.00       0.00    0.00   0.00   0.00 

  50331654                 vmk1     vmnic3 DvsPortset-0          0.00    0.00       0.00    0.00   0.00   0.00 

  50331655          vdr-vdrPort     vmnic3 DvsPortset-0          0.00    0.00       0.00    0.00   0.00   0.00 

  50331660 52305:Palo Alto Netw     vmnic2 DvsPortset-0          0.00    0.00       0.00    0.00   0.00   0.00 

  50331661 37661:Dom-Ubuntu01.e     vmnic3 DvsPortset-0          0.00    0.00       0.00    0.00   0.00   0.00 

  50331662 41267:Dom-Windows02.     vmnic3 DvsPortset-0          0.00    0.00       0.00    0.00   0.00   0.00 

  67108865           Management        n/a DvsPortset-1          0.00    0.00       0.00    0.00   0.00   0.00 

  67108866               vmnic1          - DvsPortset-1          0.00    0.00     129.70    0.25   0.00   0.00 

  67108867     Shadow of vmnic1        n/a DvsPortset-1          0.00    0.00       0.00    0.00   0.00   0.00 

ESXCLI

To view VM to dvUplink mapping

~ # esxcli network vm list

World ID  Name                         Num Ports  Networks       

--------  ---------------------------  ---------  ---------------

   37661  Dom-Ubuntu01                         1  dvportgroup-540

   41267  Dom-Windows02                        1  dvportgroup-585

   52305  Palo_Alto_Networks_NGFW_(1)          1  dvportgroup-520

~ # esxcli network vm port list -w 37661

   Port ID: 50331661

   vSwitch: DSwitch-Res01

   Portgroup: dvportgroup-540

   DVPort ID: 222

   MAC Address: 00:50:56:87:6f:a9

   IP Address: 0.0.0.0

   Team Uplink: vmnic3

   Uplink Port ID: 50331650

   Active Filters: dvfilter-generic-vmware-swsec, vmware-sfw, serviceinstance-1

To View VM to vmkernel VTEP mapping

~ # esxcli network  vswitch dvs vmware vxlan network port list --vds-name=DSwitch-Res01 --vxlan-id=5007

Switch Port ID  VDS Port ID  VMKNIC ID

--------------  -----------  ---------

      50331655  vdrPort              0

      50331661  222                  0

~ # 

~ # esxcli network  vswitch dvs vmware vxlan  vmknic list --vds-name=DSwitch-Res01

Vmknic Name  Switch Port ID  VDS Port ID  Endpoint ID  VLAN ID  IP          Netmask        IP Acquire Timeout  Multicast Group Count  Segment ID

-----------  --------------  -----------  -----------  -------  ----------  -------------  ------------------  ---------------------  ----------

vmk1               50331654  20                     0       10  172.16.1.4  255.255.255.0                   0                      0  172.16.1.0

~ # 

Central Control Plane

htb-1n-eng-dhcp10 # show control-cluster logical-switches mac-table 5007

VNI      MAC               VTEP-IP         Connection-ID

5007     00:50:56:87:6f:a9 172.16.1.4      51           

5007     00:50:56:87:92:b1 172.16.1.5      52           

5007     00:50:56:87:6e:32 172.16.1.3      45   

Please don’t hesitate to contact me if you have anymore questions.

Kind Regards

Kev

Kevin Barrass – VCDX#191

Senior NSX Solutions Architect

Network and Security Business Unit 

+44 (0)7825 034393

From: Yves Fauser <yfauser@vmware.com>

Date: Wednesday, 24 February 2016 08:59

To: David Pasek <dpasek@vmware.com>, Emanuele Mazza <emazza@vmware.com>, Dimitri Desmidt <ddesmidt@vmware.com>, Kevin Barrass <kbarrass@vmware.com>

Subject: Re: NSX Question

{Adding Emanuele, Dimitri and Kev}

Hi David,

I must admit that I don’t know the logic of how VM traffic gets placed onto the different VTEPs in a setup where multiple VTEPs are deployed per ESXi Host.

So I can’t tell you if we pin whole logical switches or individual VMs to the different VTEPs.

I’m sure one of our colleagues I added knows this and will educate me and yourself on it ;-)

Cheers,

Yves

Yves Fauser

Senior Solutions Architect

yfauser@vmware.com

Mobile: +49 172 254 7415

From: David Pasek <dpasek@vmware.com>

Date: Dienstag, 23. Februar 2016 12:17

To: Yves Fauser <yfauser@vmware.com>

Subject: NSX Question

Hi Yves.

I have a simple question but so far I have get several contradictory answers from different VMware’s NSX experts.

Let’s assume I have NSX with multiple VTEPs (2) per ESXi host. 

Is there a chance that each VM connected to the same logical switch will be load balanced across these two VTEPs?

Of course, it depends on hash algorithm result, but let’s assume hash result is unique for each VM.

Thanks in advance.

—

David Pasek, Senior Technical Account Manager

VM samples and VMX core dump on a running VM

A virtual machine is composed of several processes or userworlds that run in the VMkernel. Combined, the processes collectively make up a group. The following is a summary of components of a virtual machine:

• Virtual Machine Executable (VMX) process - A process that runs in the VMkernel that is responsible for handling I/O to devices that are not critical to performance. The VMX is also responsible for communicating with user interfaces, snapshot managers, and remote console.
• Virtual Machine Monitor (VMM) process - A process that runs in the VMkernel that is responsible for virtualizing the guest OS instructions, and manages memory. The VMM passes storage and network I/O requests to the VMkernel, and passes all other requests to the VMX process. There is a VMM for each virtual CPU assigned to a virtual machine.
• Mouse Keyboard Screen (MKS) process - A process that is responsible for rendering the guest video and handling guest operating system user input.

*************************************

To set vmsamples up on a running VM, use "vmdumper -l" to list world IDs of running VMs and then "vmdumper <worldid> samples_on" to turn it on for that VM. This will last until the VM is power cycled/powered off or until a samples_off command is run.


Turn VM sample on
#vmdumper <worldid>samples_on

VMM core dump ...
vmdumper <worldid> unsync
vmdumper <worldid> sync

VMX core dump ...
vmdumper <worldid> vmx
vmdumper <worldid> vmx_force

VMkernel core dump ...
You can collect the live dump without crashing the box using -
   localcli --plugin-dir /usr/lib/vmware/esxcli/int/ debug livedump perform

Turn VM sample off
#vmdumper <worldid>samples_off

Refer https://wiki.eng.vmware.com/DebuggingEsx#Creating_a_Live_Crash_Dump_for_ESXi

***************************************
Additional info:
Interpreting virtual machine monitor and executable failures (1019471)

Tags:
esxi, vmkernel, debug, coredump

FCoE Notes

QLA HBA - 

http://www.qlogic.com/OEMPartnerships/Dell/Documents/ds_QLE8152.pdf

Host Connectivity

• On QLogic CNAs, set the Link Down Timeout to 60 seconds (the default is 30 seconds) in the Advanced HBA Parameters. This is necessary to ensure proper recovery or failover if a link fails or becomes unresponsive.
  
  
  Switch Configuration
  
  fka-adv-period
  
  
  VFC down due to FIP keepalive misses
  The VFC goes down due to FIP keepalive misses.
  Possible Cause
  When FIP keepalives (FKA) are missed for a period of approximately 22 seconds, this means that approximately three FKAs are not continuously received from the host. Missed FKAs can occur for many reasons, including congestion or link issues.
  FKA timeout : 2.5 * FKA_adv_period.
  The FKA_adv_period is exchanged and agreed upon with the host as in the FIP advertisement when responding to a solicitation.
  Observe the output from the following commands to confirm FKA misses:
•  show platform software fcoe_mgr info interface vfc <id>
•  show platform software fcoe_mgr event-history errors
•  show platform software fcoe_mgr event-history lock
•  show platform software fcoe_mgr event-history msgs
•  show platform fwm info pif ethernet <bound-ethernet-interface-id>
• Solution
  Sometimes when congestion is relieved, the VFC comes back up. If the symptom persists, then additional analysis is required. The possible considerations are:
  
• The host stopped sending the FKA.
• The switch dropped the FKA that was received.
•  
  
  
  
    

VMtools - parameters

/v /qb-! REINSTALLMODE=vomus ADDLOCAL=All REMOVE=Hgfs,WYSE,Audio,BootCamp,Unity,VShield REBOOT=ReallySuppress

/v /qb-! REINSTALLMODE=vomus ADDLOCAL=All REBOOT=ReallySuppress
/S /v "/qn /l*v ""%TEMP%\vmtools-inst.log"" REBOOT=ReallySuppress ADDLOCAL=ALL REMOVE=Hgfs,WYSE,Audio,BootCamp,Unity,FileIntrospection,NetworkIntrospection"


/S /v "/qn /l*v ""%TEMP%\vmtools-inst.log"" REBOOT=ReallySuppress ADDLOCAL=ALL REMOVE=Hgfs,WYSE,Audio,BootCamp,Unity"

What's new in PowerCLI 6.3 R1

PowerCLI 6.3 R1 introduces the following new features and improvements:

Get-VM is now faster than ever!

The Get-VM Cmdlet has been optimized and refactored to ensure maximum speed when returning larger numbers of virtual machine information. This was a request which we heard time and time again, when you start working in larger environments with thousands of VMs the most used cmdlet is Get-VM so making this faster means this will increase the speed of reporting and automation for all scripts using Get-VM. Stay tuned for a future post where we will be showing some figures from our test environment but believe me, it’s fast!

New-ContentLibrary access

New in this release we have introduced a new cmdlet for working with Content Library items, the Get-ContentLibraryItem cmdlet will list all content library items from all content libraries available to the connection. This will give you details and set you up for deploying in our next new feature…. 

The New-VM Cmdlet has been updated to allow for the deployment of items located in a Content Library. Use the new –ContentLibrary parameter with a content library item to deploy these from local and subscribed library items, a quick sample of this can be seen below:

$CLItem = Get-ContentLibraryItem TTYLinux
New-VM -Name "NewCLItem" -ContentLibraryItem $CLItem -Datastore datastore1 -VMHost 10.160.74.38

Or even simpler….

Get-ContentLibraryItem -Name TTYLinux | New-VM -Datastore datastore1 -VMHost 10.160.74.38

ESXCLI is now easier to use

Another great feature which has been added has again come from our community and users who have told us what is hard about our current version, the Get-Esxcli cmdlet has now been updated with a –V2 parameter which supports specifying method arguments by name.

The original Get-ESXCLI cmdlet (without -v2) passes arguments by position and can cause scripts to not work when working with multiple ESXi versions or using scripts written against specific ESXi versions.

A simple example of using the previous version is as follows:

$esxcli = Get-ESXCLI -VMHost (Get-VMhost | Select -first 1)

$esxcli.network.diag.ping(2,$null,$null,“10.0.0.8”,$null,$null,$null,$null,$null,$null,$null,$null,$null)

Notice all the $nulls ?  Now check out the V2 version:

$esxcli2 = Get-ESXCLI -VMHost (Get-VMhost | Select -first 1) -V2

$arguments = $esxcli2.network.diag.ping.CreateArgs()

$arguments.count = 2

$arguments.host = "10.0.0.8"

$esxcli2.network.diag.ping.Invoke($arguments)

Get-View, better than ever

For the more advanced users out there, those who constantly use the Get-View Cmdlet you will be pleased to know that a small but handy change has been made to the cmldet to enable it to auto-complete all available view objects in the Get-View –ViewType parameter, this will ease in the use of this cmdlet and enable even faster creation of scripts using this cmdlet.

Updated Support

As well as the great enhancements to the product listed above we have also updated the product to make sure it has now been fully tested and works with  Windows 10 and PowerShell v5, this enables the latest versions and features of PowerShell to be used with PowerCLI.

PowerCLI has also been updated to now support vCloud Director 8.0 and vRealize Operations Manager 6.2 ensuring you can also work with the latest VMware products.

More Information and Download

For more information on changes made in vSphere PowerCLI 6.3 Release 1, including improvements, security enhancements, and deprecated features, see the vSphere PowerCLI Change Log. For more information on specific product features, see the VMware vSphere PowerCLI 6.3 Release 1 User’s Guide. For more information on specific cmdlets, see the VMware vSphere PowerCLI 6.3 Release 1 Cmdlet Reference.

You can find the PowerCLI 6.3 Release 1 download HERE. Get it today!