Wednesday 17 February 2016

Large Packet Loss At Guest OS Level in VMware ESXi When Using VMXNET3


Symptoms

When using the VMXNET3 driver on ESXi 4.x, 5.x or 6.0, you see significant packet loss during periods of very high traffic bursts. Symptoms may include one or more of the following:

  • Poor performance
  • Packet loss
  • Network latency
  • Slow data transfer

Causes

This issue occurs when packets are dropped during  high traffic bursts. This can occur due to a lack of receive and transmit buffer space or when receive traffic is speed-constrained, as, for example, with a traffic filter.

Resolutions

#1 Increase Windows Buffer Settings:


  1. Click Start > Control Panel > Device Manager.
  2. Right-click vmxnet3 and click Properties.
  3. Click the Advanced tab. 
  4. Click Small Rx Buffers and increase the value. The default value is 512  and the maximum is 8192.
  5. Click Rx Ring #1 Size and increase the value. The default value is 1024 and the maximum is 4096.


Notes:
These changes will happen on the fly, so no reboot is required. However, any application sensitive to TCP session disruption can likely fail and have to be restarted. This applies to RDP, so it is better to do this work in a console window.
This issue is seen in the Windows guest OS with a VMXNET3 vNIC. It can occur with versions besides 2008 R2.
It is important to increase the value of Small Rx Buffers and Rx Ring #1 gradually to avoid drastically increasing the memory overhead on the host and possibly causing performance issues if resources are close to capacity.
If this issue occurs on only 2-3 virtual machines, set the value of Small Rx Buffers and Rx Ring #1 to the maximum value. Monitor virtual machine performance to see if this resolves the issue.
The Small Rx Buffers and Rx Ring #1 variables affect non-jumbo frame traffic only on the adapter.

#2 Change the Virtual Machine network adapter type to E1000:

To change the network adapter on a virtual machine:
Right-click the virtual machine and click Edit Settings.
Click Add.
Click Ethernet Adapter and click Next.
In the Type field, select E1000.
Select the desired Network Connection label.
Select Connect at power and click Next.
Click Finish, then click OK.

At this point, you may remove the old adapter and configure the new network adapter with your desired network settings:
Right-click the virtual machine and click Edit Settings.
Click the original VMXNET3 network adapter.
Make a note of the selected Network Connection label.
Click Remove.
Click on the new E1000 network adapter.
Change the Network Connection label to the value you noted in step 3.
Click OK.

Note: The virtual machine may require a reboot for the changes to take effect.

#3 Disable the TCP & UDP Checksum Offloading feature in Windows OS:

The issue may be caused by Windows TCP Stack offloading the usage of the network interface to the CPU. To resolve this issue, disable the TCP Checksum Offload feature, as well enable  RSS on the VMXNET3 driver.

Open the command prompt as administrator and run these commands:
netsh int tcp set global chimney=disabled
netsh int tcp set global autotuninglevel=disabled
netsh int tcp set global congestionprovider=none
netsh int tcp set global ecncapability=disabled
netsh int ip set global taskoffload=disabled
netsh int tcp set global timestamps=disabled
netsh int tcp set global dca=disabled

To validate type:
netsh int tcp show global

#4 Enable Received Side Scaling (RSS):

Only required where using multiple vCPUs.

Open the command prompt as administrator and run these commands:
netsh int tcp set global rss=enabled

To validate type:
netsh int tcp show global

References




Monday 7 September 2015

Windows Server Backup

# Install the Windows Server Backup GUI & CLI tools using PowerShell (as Admin):
Import-Module ServerManager
Add-WindowsFeature Backup-Features -IncludeAllSubFeature (2008/R2)
Add-WindowsFeature Windows-Server-Backup -IncludeAllSubFeature (2012/R2)

# Save one or more of the following scripts to a batch file (e.g. C:\Scripts\RunServerBackup.bat)

# Command to perform a Bare Metal Recovery (BMR) full OS backup:
WBADMIN START BACKUP -backupTarget:D: -allCritical -systemState -quiet
# Command to backup only the System state and keep last 5 versions:
WBADMIN START SYSTEMSTATEBACKUP -backupTarget:D: -quiet
WBADMIN DELETE SYSTEMSTATEBACKUP -keepVersions:5 -backupTarget:D: -quiet
# Command to log the current backups available for restore:
WBADMIN GET VERSIONS -backupTarget:D: >D:\Backup.txt

# Create a new scheduled task to run a server backup at 5am Monday to Friday:
SCHTASKS /Create /RU "SYSTEM" /SC WEEKLY /D MON,TUE,WED,THU,FRI /TN ServerBackup /RL HIGHEST /ST 05:00 /TR "C:\Scripts\RunServerBackup.bat"

# Check the size of the VSS storage space reserved for backups:
vssadmin List ShadowStorage /On=D:

# Adjust the size of the VSS storage space reserved for backups:
vssadmin Resize ShadowStorage /For=D: /On=D: /MaxSize=40%

# Create an AD snapshot (e.g. before making a change):
ntdsutil "Activate Instance NTDS" snapshot create quit quit

Delete old backups

DiskShadow.exe
List shadows ALL
Delete shadows ID <Shadow Copy ID>
Delete shadows OLDEST D:
Delete shadows ALL
Wbadmin delete catalog
Wbadmin delete systemstatebackup

Service details

Service name: wbengine
Display name: Block Level Backup Engine Service
Description: The WBENGINE service is used by Windows Backup to perform backup and recovery operations. If this service is stopped by a user, it may cause the currently running backup or recovery operation to fail. Disabling this service may disable backup and recovery operations using Windows Backup on this computer.
Path to exectuable: "C:\Windows\system32\wbengine.exe"
Startup type: Manual
Log on as: Local System account
Batch restart service: net stop wbengine && net start wbengine

GUI details

Name: Windows Server Backup
Target: wbadmin.msc
Start in: "%windir%\system32"
Comment: Perform a backup or recovery of this server.

References



Monday 3 August 2015

The 497 Day Uptime Bug

Issue

  1. All the TCP/IP ports that are in a TIME_WAIT status are not closed after 497 days from system startup. Therefore, TCP/IP ports may be exhausted, and new TCP/IP sessions may not be created. All the TCP/IP ports that are in a TIME_WAIT status are not closed after 497 days from system startup. Therefore, TCP/IP ports may be exhausted, and new TCP/IP sessions may not be created.
  2. TCP/IP chimney offloading fails after 248.5 days. Therefore, systems will stop responding after 248.5 days if offloading connections are being used.

Resolution

  • Schedule more frequent server reboots
  • Apply a hotfix

Background

The reason that 497  is a problem number is because of the use of a 32 bit counter to record uptime.   If you record a tick for every 10 msec of uptime, then a 32-bit counter will overflow after approximately 497.1 days.  This is because a 32 bit counter equates to 2^32, which can count 4,294,967,296 ticks.  Because a tick is counted every 10 msec, we create 8,640,000 ticks per day (100*60*60*24).  So after 497.102696 days, the counter will overflow.

Some systems have a problem at 248.551348 days (half of that) if they use a signed 32 bit integer to store the value (one less bit to work with).

Note that this bug does not only affect Microsoft products. Other vendors to be affected by this bug include: Avaya, Brocade, Cisco, EMC, QLogic and VAX/VMS.

Links

Monday 27 July 2015

Best Practices for Virtualizing Domain Controllers

Virtual DC Best Practices


  1. DCs require VM High Availability
  2. Never pause, clone or snapshot a DC
  3. Not all backups are created equal
  4. Avoid clock drift
  5. Don't overprovision resources
  6. Ensure backups actually work
  7. Implement anti-affinity rules
  8. Separate client and administrative traffic
  9. Prioritise quick object restores
  10. Monitor storage performance
  11. Remain a bit physical
  12. Have a plan for disaster recovery


Reference documents

Monday 20 July 2015

Different digital certificate formats

Certificates can be exported in a number of different formats. This blog aims to clear up any confusion around what these formats are.

When exporting certificates in Windows the following options are available.

1. Export the private key:

  • .PFX format - Personal Information Exchange - PKCS #12
2. Do not export the private key:

  • .CER - DER encoded binary X.509 - use this for non-Windows devices that require the cert.
  • .CER - Base-64 encoded X.509 - use this for Windows devices that require the cert.
  • .P7B - Cryptographic Message Syntax Standard - PKCS #7 Certificates - use this when you want to export the issuing and root CA certs bundled with the server cert.


Tuesday 14 July 2015

How to migrate a XenApp database

Migrating the Database to a Different Version of the SQL Server

Migrating from one database version to the other might be necessary to move the data store to a more powerful server. The best method for migrating between versions of the database is to back up and restore the database using the utilities provided by the database software vendor.

To point a XenApp Server farm to a new database, complete the following steps:
Note: For the best performance, complete this procedure on the data collectors after all other servers are reconfigured.
  • Back up the existing farm database and restore the database to the new server.
  • Create a new DSN file that points to the restored database.
  • Run the dsmaint config command on the server with the new DSN file.
  • Stop and restart the IMA Service.
Important: Restarting the IMA Service instead of restarting the server might cause the SNMP service to initiate Dr. Watson, if SNMP is enabled. This error is benign.
  • Ensure that the server is pointing to the new data store by verifying the following registry setting:
HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\IMA\DataSourceName
  • If the IMA Service started successfully, copy the new DSN file to all servers in the farm.
  • Run the dsmaint config command to change the IMA Service configuration on all remaining servers in the farm.
  • Stop and restart the IMA Service on all servers in the farm.
Tip: You can execute Steps 6 through 8 on all the servers from a simple batch file placed in a central location.

Applicable products

  • XenApp 6.5 for Windows Server 2008 R2
  • XenApp 6.0 for Windows Server 2008 R2
  • XenApp 5.0 for Windows Server 2008

Further reading


Citrix Receiver customizations

External links