Source vCenter Server has duplicate names in a network folder.

During upgrade from vsphere 6.0 to 6.5 you can got the following error:

Error

Source vCenter Server has duplicate names in a network folder.

Resolution

Please change name of Distributed Virtual Switch or Distributed Virtual Portgroup with following names: {dvSwitch, } to ensure unique names in each network folder before upgrade. Refer to VMwareKnowledge Base article 2147547 for more details.

 

 

vSphere 6.5 allows only unique names across all Distributed Virtual Switches and Distributed Virtual Portgroups in the same network folder. Earlier versions of vSphere allowed a Distributed Virtual Switch and a Distributed Virtual Portgroup to have the same name. If you attempt to upgrade from a version that allows duplicate names, the upgrade fails.

 

After logging to the VCSA over SSH or console, you can easily connect to the PostgreSQL server locally using psql:

/opt/vmware/vpostgres/current/bin/psql -U postgres -d VCDB

List entries in the Distributed Virtual Portgroup table by running this command:

select id,dvportgroup_name from VPX_DVPORTGROUP;

List entries in the Distributed Virtual Switch table table by running this command:

select id,name from VPX_DVS;

 

List entries in the entities table table by running this command:

select id,name,parent_id from VPX_ENTITY;

Note: The parent_id for the conflicting Distributed Virtual Switch and Distributed Virtual Portgroup names. The same parent_id indicates the same network folder. Change only the duplicate names in the same network folder.

 

Detect duplicate names of Distributed Virtual Portgroups and Distributed Virtual Switches by running the following command:

select id,dvportgroup_name from VPX_DVPORTGROUP where dvportgroup_name in (select name from VPX_DVS group by name) AND dvportgroup_name in (select name from VPX_ENTITY group by name,parent_id having count(*) > 1);

 

 

In my case, I have 3 Distribuited Virtual Portgroup Duplicated

Rename Distributed Virtual Portgroups or Distributed Virtual Switches

  • Update the Distributed Virtual Portgroup table by running these commands:

    update VPX_DVPORTGROUP set dvportgroup_name=’dvSwitch_External 1′ where id=
    21402;

    update VPX_ENTITY set name=’dvSwitch_External 1′ where id=
    21402;

    update VPX_DVPORTGROUP set dvportgroup_name=’dvSwitch_Vmotion 1′ where id=
    20949;

    update VPX_ENTITY set name=’dvSwitch_Vmotion 1′ where id=
    20949;

    update VPX_DVPORTGROUP set dvportgroup_name=
    dvSwitch_Rete_2.X 1′ where id=
    21405;

    update VPX_ENTITY set name=’dvSwitch_Rete_2.X 1′ where id=
    21405;


    Note: After running each command, you will see the output as UPDATE 1.


You also could have the Distribuited Virtual Switch, you can update with this command

  • Update the Distributed Virtual Switchtable by running these commands:

    update VPX_DVS set name=’DSwitch 2′ where id=7;

    update VPX_ENTITY set name=’DSwitch 2′ where id=7;

    Note: After running each command, you will see the output as UPDATE 1.

Verify that there are no duplicate names in the same network folder

After you rename the Distributed Virtual Portgroups or Distributed Virtual Switch, verify that there are no duplicate names in the same network folder by running this command:

select id,dvportgroup_name from VPX_DVPORTGROUP where dvportgroup_name in (select name from VPX_DVS group by name) AND dvportgroup_name in (select name from VPX_ENTITY group by name,parent_id having count(*) > 1);

Now should be solved.

VMware View 5.1 and SSL Certificate Replacement

The procedure to replace SSL certificates has changed in recently released VMware View 5.1 and differs from 5.0 or earlier versions. The main difference is that native Windows certificate store is used. Also it is now necessary to replace or at least to verify self signed certificates otherwise the View infrastructure will not work properly.
Which servers need to replace the certificates? View Connection Managers, Security servers and View Composer. Also vCenter certificate must be replaced or validated.
Although the certificate replacement procedure is described in the manual, the description is very brief and it took me some time to figure it out.

The Setup

My lab configuration is following. View Composer is installed together with vCenter. I have two View Connection Managers; one for internal connections and one for external internet connections. I do not use Security server as I use port forwarding to the external View Connection Manager. All servers are in the domain with Enterprise CA which uses self signed certificate.

View Composer Certificate

My View Composer server is coexisting with vCenter so I did not need to generate new certificate. I just imported the vCenter certificate from C:\ProgramData\VMware\VMware VirtualCenter\SSL into the local Windows certificate (Personal) store via MMC Certificates Snap-in.


Select the .pfx file which contains both private key and the certificate.



Now we have to stop the View Composer process and run SviConfig command to replace the certificate:

C:\Program Files (x86)\VMware\VMware View Composer>SviConfig.exe -operation=replacecertificate -delete=false
and select the new certificate.


Start the View Composer process again and check the status in the View Administrator.


View Connection Servers

Here we have to generate the certificates. To do this I am again using the Certificates Snap-in. However prior to that I needed to give both of my Connection Server access to Web Server certificate template.
On my CA open the Certificate Templates Management Console Snap-in and open properties of Web Server certificate template.


Open the security tab and add both View Connection computers and give them read, write and enroll permissions.



Now we can go to each Connection Server Certificates Snap-in and right click, select All Tasks and Request New Certificate.


Select Active Directory Enrollment Policy and Web Server certificate template.


Now we have to add FQDN and additional info to the certificate. Click the More information is required … link.
Type in the Common name (FQDN), Country, Locality, Organization and any other info that will be visible inside the certificate. If your Connection server uses different internal (viewcs2.fojta.com) and public (public.url.com) Fully Qualified Domain Names add both and do the same for the Type: DNS field. The end result should look like this:


And do not forget to make private key exportable in the Private Key tab / Key options.


Click enroll and finish.
Now we should see the newly created certificate. Last thing we need to do is to change the certificate Friendly Name to vdm. This can be done in the certificate properties. Also we have to rename the original certificate (vdm.old)


Once this is done we can restart the View services.
Repeat for all other View Connection servers and check the result in the View Administrator.


View Clients

As I said at the beginning my CA uses self signed certificate so I have to make sure all the non-domain PCs I use to connect to my View desktops imported the CA Root certificate into the Trusted Root Certification Authorities store.

How to Configure VMware View’s Event Database with SQLExpress


For many small environments, labs, demo centers, et cetera, the vCenter database lives on the vCenter server using the default SQLExpress installation from the View installation.

To proceed with the configuration below, you will need to install SQL S erver Management Studio Express (SSMSE).  This will give us a GUI interface for the SQL Express installation. I’m by no means a SQL expert, so if there’s a better way to do this, I’m all open. I mostly pulled information from this thread.

  • Open SSMSE, right click the top item, SQLEXP_VIM and go to <strong<security< strong=””>.</strong<security<>
  • Set the server to use SQL Server and Windows Authentication mode.
  • Right click Databases and create a new database (e.g. ViewEvents).
  • Under Security –> Logins, right-click and select New Login.
  • Create a login (e.g. viewdb), use SQL Authentication and set the default database to ViewEvents.

  • Under User Mapping, click ViewEvents (viewdb should automatically be populated in the User column).
  • In the Database role membership for: msdb sub-pane, check db_owner.
  • Ensure Remote Connections are allowed. 
  • Determine the port in use by SQL Express by opening SQL Server Configuration Manager.
  • Expand SQL Server 2005 Network Configuration and select Protocols for SQLEXP_VIM.
  • Right-click TCP/IP and select Properties.
  • Click the IP Addresses tab.
  • In IP1 should be the IP address in use by the vCenter server (e.g. 98.172.175.86).
  • Set Enabled to Yes.
  • If TCP Dynamics Ports is set to 0 (which it likely is), take note of the TCP Dynamic Ports field towards the bottom (e.g. 1160).
  • Open services.msc and restart the SQL Express Server service.
  • Go to the View Admin page (https://viewserver/admin).
  • Expand View Configuration and select Event Configuration.
  • Click Edit.
  • Enter the FQDN of the vCenter server and ONLY the FQDN of the vCenter server (not SQLEXP_VIM or anything else).
  • Set Database Type to Microsoft SQL Server.
  • Set the Port to the static or dynamic port as determined above (e.g. 1160).
  • Set the Database name to the database name (e.g. ViewEvents).
  • Enter the username create for SQL authentication (e.g. viewdb).  Enter the password associated with this account.
  • Enter a table prefix (e.g. VDI).

VMware vCenter Mobile Access (vCMA)

VMware vCenter Mobile Access (vCMA) è una virtual appliance che permette la gestione dei datacenter tramite dispositivi mobile come smartphone e tablet (iPad).

Utilizzando il browser presente nei dispositivi mobile o da applicazioni iPad, l’amministrazione e il troubleshooting negli ambienti VMware può essere effettuata da qualsiasi parte nel mondo.

1. PROCEDURA 
Scaricare
 dal sito VMware la virtual appliance vCenter Mobile Access attualmente alla versione 1.2.0.64 (287 MB).

Scompattare il file .zip estraendo i due file contenuti:

  1. system.vmdk
  2. vCenterMobileAccess-1.2.0.64.ovf

Da vSphere Client collegarsi al server ESX(i) in cui si vuole caricare la virtual appliance ed effettuare tramite File –> Deploy OVF Template l’installazione.


Tramite il bottone Browse selezionare il file OVF scaricato e cliccare su Next.


Viene visualizzata la finestra con i dettagli dell’appliance da installare. Click su Next.


Cliccare su Accept per accettare l’EULA e click su Next per continuare.


Assegnare il nome della virtual machine (default vCenter Mobile Access). Click Next per proseguire.


Opzionalmente assegnare la virtual machine ad un resource pool eventualmente configurato.


Selezionare l’opzione di Disk Format richiesto e cliccare su Next.


Cliccare sul bottone Finish per iniziare l’installazione.


L’appliance viene caricata nello storage.


Terminata l’installazione, la nuova virtual machine compare nel resource pool precedentemente specificato.


2. CONFIGURAZIONE DELL’ APPLIANCE 
Avviare l’appliance
 ed accedere alla console per effettuare la configurazione.


Se nella rete è presente un server DHCP, un indirizzo IP è assegnato alla virtual machine rilevabile nella schermata iniziale del VCMA. Se non è presente nessun DHCP è necessario accedere alla configurazionedella rete tramite la voce Configure Network assegnando un IP con cui accedere all’appliance.


Accedere al sistema tramite browser digitando l’indirizzo:

https://IP_address:5480

Compare la schermata di Login. Digitare le credenziali di default per accedere e cliccare sul bottoneLogin.

User name: root 
Password: vmware


Effettuato il login si presenta la schermata System Information da cui è possibile effettuare operazioni diReboot, Shutdown e configurazione della rete.


Cliccare su Network per assegnare un IP statico al sistema.


Impostati i parametri di rete, cliccare su Save Settings per salvare la configurazione.


E’ opportuno cambiare l’hostname e la password del sistema per meglio identificarlo nella rete rendendo l’accesso più sicuro. Cliccare su Login.


Effettuare il login con le credenziali di default e lanciare il comando per modificare l’hostname.

# vi /etc/hostname


Digitare il valore richiesto e salvare.


Editare il file /etc/sysconfig/network.

# vi /etc/sysconfig/network


Modificare i valori di hostname ed eventualmente domainname.


E’ consigliato cambiare la password per mettere in sicurezza il sistema da accessi non autorizzati.

# passwd


3. TESTARE LA FUNZIONALITA’ 
Utilizzando un dispositivo mobile tipo iPad, smartphone o anche il semplice PC, effettuare l’accesso al sistema tramite browser utilizzando il nuovo IP_address o dns_name. La sintassi da utilizzare è la seguente:

https://IP_Address/vim

Nell’esempio “vcma” è il DNS name assegnato al sistema. Nella finestra di Login digitare i parametririchiesti e cliccare successivamente sul bottone Log In.

Server: IP_Address o DNS_name vCenter Server 
Username: utente per accedere a vCenter Server 
Password: 


Si accede alla pagina di gestione del datacenter.


Accedendo ad esempio ad Hosts and Clusters è possibile gestire i vari server ESX(i) e cluster del datacenter.


Utilizzando smartphone/tablet, l’accesso alla struttura del datacenter VMware risulta più efficiente permettendo l’amministrazione anche fuori ufficio fornendo un servizio tempestivo in caso di necessità.

LACP and ESXi 5.1

LACP support is only available on ESXi 5.1. How to configure and verify the new LACP NIC Teaming option in ESXi 5.1. LACP – Link Aggregation Control Protocol is used to form dynamically Link Aggregation Groups between network devices and ESXi hosts.

With vSphere 5.1 we have the possibility of using LACP to form a Link Aggregation team with physical switches, which has some advantages over the ordinary static method used earlier. To be able to combine several NICs into one logical interface correct configuration is needed both on the vSwitches and on the physical switches. Some common configuration errors did however this kind of setup somewhat risky, but will now be easier in ESXi 5.1.

On the earlier releases of ESXi the virtual switch side must have the NIC Teaming Policy set to “IP Hash” and on the physical switch the attached ports must be set to a static Link Aggregation group, called “Etherchannel mode on” in Cisco and “Trunk in HP Trunk mode” on HP devices.


To use dynamic Link Aggregation setup you must have ESXi 5.1 together with virtual Distributed Switches version 5.1. This could either be a new Distributed vSwitch or an already existing 4.0, 4.1 or 5.0 switch that is upgraded to version 5.1.


Even if it is not needed technically for LACP, it is always good to enable LLDP to make the configuration on the physical switch simpler. Above is the new configuration box on the Web Client of vSphere 5.1.


Now it is easy to verify the exact ports on the physical switch attached to the specific ESXi host. Above we can see that vmnic2 and vmnic3 from the ESXi host is connected to certain physical switch ports. This information is needed soon, but we must first setup the LACP connection on the ESXi host.


In the Uplink portgroup settings we have the new option of enabling LACP. Note that you must use the Web Client to reach this setting. Change from default Disabled to Enabled to active LACP. We can now select either default “passive” or “active” mode.

Passive means in this context that the ESXi vmnics should remain silent and do not send any LACP BPDU frames unless something on the other side initiates the LACP session. This means that the physical switch must start the LACP negotiation.


All other portgroups on the Distributed vSwitch must be set to “IP Hash“, just as in earlier releases. The LACP setting is only configured on the Uplink-portgroup.

We must now complete the setup on the physical switch. In this example we have a HP Switch (Procurve 5406-zl) and the commands shown here will work on all HP switches (excluding the A-series). As displayed earlier we could use the LLDP feature to find the actual switchports connected to the ESXi host, in this example the ports are called A13 and A14.


In the HP command line interface a collection of switch port in a Link Aggregation Group is called “Trunk“. (“Port Channel” or “Etherchannel” on Cisco devices.) The command above creates a logical port named Trk1from the physical ports A13 and A14 using LACP.

The default mode on HP LACP is active, which means that the switch will now start negotiating LACP with the other side, here our ESXi 5.1 host.

Now we get to the real advantage of the dynamic LACP protocol: we could verify the result. In ordinary static trunk/etherchannel we can not really know if the links are correctly configured and cables properly patched, which is often responsible for a number of network issues. However, with LACP we could see if the setup of link aggregation group was completed or not.


With the command “show lacp” we could see that the physical switch has successfully found LACP partners on both interfaces and that the link is now up and running in good order. This is the great feature of LACP, meaning that links will not get up in running order if the other side is not a LACP partner.
This prevents lots of potential network disturbances and makes it much more easy to verify link aggregation configuration. It should be noted that LACP, despite popular belief, does not make the network load distribution any different or more optimized. Chris Wahl has a good writeup demystifying many LACP myths here.

The main benefit of LACP is to avoid misconfigured and non-matching switch-to-switch settings. LACP is as such a welcomed new feature in ESXi 5.1, however is only available on the Distributed vSwitches.

Quickest Way to Patch an ESX/ESXi Using the Command-line

As you know, when it comes to automating patch management for your vSphere infrastructure, we highly recommend leveraging our vSphere Update Manager (VUM) which is part of the vSphere vCenter Suite to help simplify the update process. Though not all environments have the luxury of running vCenter Server to manage their ESX(i) hosts. An example of this could be 1-2 hosts running at a ROBO (remote office/branch office) site or single test/dev host in a home or office lab where VUM is not available.

However, it is still possible to patch/upgrade your ESX(i) host using the command-line without the need of VUM, but you will have to manually identify the patch dependencies and ensure host compliance.

Depending on the version of ESX or ESXi you are running, you may have several options that could include local and/or remote command-line utilities that are available in following four forms:

  • ESX Service Console
    • esxupdate – Local utility found on classic ESX hosts to manage/install patches
  • ESXi Shell
    • ESXCLI – Local utility found on ESXi 5.0 hosts that can be used manage/install patches
  • vCLI (Windows/Linux or use vMA)
    • vihostupdate35 – Remote utility to manage/install patches for ESXi 3.5
    • vihostupdate – Remote utility to manage/install patches for ESX(i) 4.0 & 4.1
    • ESXCLI – Remote utility to manage/install patches for ESXi 5.0 (patch capability introduced in vSphere 5 for ESXi 5.0 hosts only)
  • PowerCLI(Windows)
    • InstallVMHostPatch – Remote utility using PowerCLI to manage/install patches for ESX(i) 4.0 and 4.1

Note: If you are using vSphere Hypervisor (Free ESXi), you will not be able to leverage any of the the remote CLI’s but you can still use the local CLI.

Here is a table summarizing all available command-line options based on the version of ESX(i) you are running:

Hypervisor Version

Local Command

vCLI Remote Command

PowerCLI Remote Command

ESX 3.5

esxupdate −−bundle=<zip> update

N/A

N/A

ESXi 3.5

N/A

vihostupdate35
−−bundle=<zip> −−install

N/A

ESX 4.0

esxupdate −−bundle=<zip> update

vihostupdate <<bundle=<zip> −−install

Install-VMHostPatch

ESXi 4.0

N/A

vihostupdate −−bundle=<zip> −−install

Install-VMHostPatch

ESX 4.1

esxupdate −−bundle=<zip> update

vihostupdate −−bundle=<zip> −−install

Install-VMHostPatch

ESXi 4.1

N/A

vihostupdate −−bundle=<zip> −−install

Install-VMHostPatch

ESXi 5.0

esxcli software vib install −−depot=/vmfs/volumes/[datastore]/<zip>

esxcli software vib install −−depot=/vmfs/volumes/[datastore]/<zip>

Install-VMHostPatch
Or Get-ESXCLI with the local command referenced in this table.

Note: When you download patches from VMware, there is an associated VMware KB article and it provides a link to the patch management documentation. You should always refer to that for more details and information for different methods of applying a patch.

Here is an example of using esxupdate on a classic ESX host. The patch bundle needs to be uploaded to ESX host using scp or winSCP and then specifying the full path on the command-line:

$ esxupdate −−bundle=ESX400-200907001.zip update

Here is an example of using the remote vihostupdate utility for an ESXi host, you will need to specify the ESXi host using the −−server parameter and −−username/−−password for remote authenication. You may choose to leave off −−password and you will be prompted to enter your credentials. The patch bundle does not need to be uploaded to ESXi host, it can reside on the system that is running the vihostupdate command. During the execution, the patch bundle will automatically be transfered to the host:

$ vihostupdate −−server [ESXI-FQDN] −−username [USERNAME] −−bundle=ESXi410-201011001.zip −−install

Here is an example of using the local esxcli utility for an ESXi 5.0 host. The patch bundle needs to be uploaded to ESXi host using scp or winSCP and then specifying the full path on the command-line:

$ esxcli software vib install −−depot=/vmfs/volumes/datastore1/ESXi500-201112001.zip

Here is an example of using the remote esxcli utility for an ESXi 5 host, you will need to specify the ESXi host using the −−server parameter and −−username/−−password for remote authenication. You may choose to leave off −−password and you will be prompted to enter your credentials. The patch bundle needs to be uploaded to ESXi host using scp/winSCP or vCLI’s vifs utility and then specifying the full path on the command-line:

$ vifs −−server [ESXI-FQDN] −−username [USERNAME] -p ESXi500-201112001.zip “[datastore1] ESXi500-201112001.zip”
$ esxcli −−server [ESXI-FQDN] −−username [USERNAME] software vib install −−depot=/vmfs/volumes/datastore1/ESXi500-201112001.zip

Note: In ESXi 5, −−depot only supports local server path or remote URL. The latter is to help centralize the location of your patches and help reduce manual transfer. This is why you need to transfer the patch to host if you do not have a patch depot.

Here is an example of using Install-VMHostPatch utility for an ESXi host:

Get-VMHost ESXI-FQDN | Set-VMHost -State Maintenance
$DS = Get-VMHost ESXI-FQDN | Get-Datastore datastore1
Copy-DatastoreItem C:\tmp\ESXi500-201112001\ $DS.DatastoreBrowserPath -Recurse
Get-VMHost ESX-FQDN | Install-VMHostPatch -Hostpath “/vmfs/volumes/datastore1/ESXi500-201112001/metadata.zip”

Note: The Install-VMHostPatch cmdlet does have a -LocalPath parameter for you to specify a local path to the patch. For larger files it is recommended you use the Copy-Datastore cmdlet to upload the file to a datastore on the host and then the -HostPath parameter as can be seen in the example above.

As you can see over the releases, we have had several methods of patching a host using the command-line both locally/remotely and it may not always be intuitive. When we converged to only ESXi with the release of vSphere 5.0, you will see that patching from the command-line has also converged to a single command-line utility using ESXCLI and a common patch format called a VIB. ESXCLI was first introduced in vSphere 4.0 and it had some limited capabilities. With vSphere 5.0, it has been significantly enhanced and now supports patching as one of it’s many capabilities. The syntax and expected output is exactly the same if you execute ESXCLI locally or remotely on an ESXi host with the exception of the remote authentication that is required for a remote execution. This should provide for a better user experience and consistency going forward.

An alternative method to patching from the command-line if you do not have VUM is using VMware Go, which is an online service (SaaS) provided by VMware. VMware Go can help manage your ESXi host but it also provides a patching capability similar to that of VUM.

Howto get UUI per scsi_id on VMWare?

With command scsi_id you can get a unique SCSI identifier of a device
but on VMWare you become nothing!(ID_SERIAL) when run scsi_id
 
Before:

[root@oel57 ~]# scsi_id -g -a -x -p 0x83 -s /block/sdc/sdc1

ID_VENDOR=VMware,

ID_MODEL=VMware_Virtual_S

ID_REVISION=1.0

ID_SERIAL=

ID_TYPE=disk

ID_BUS=scsi

[root@oel57 ~]# udevinfo -q all -p /block/sdc/sdc1

P: /block/sdc/sdc1

N: sdc1

S: disk/by-path/pci-0000:00:10.0-scsi-0:0:2:0-part1

E: ID_VENDOR=VMware,

E: ID_MODEL=VMware_Virtual_S

E: ID_REVISION=1.0

E: ID_SERIAL=

E: ID_TYPE=disk

E: ID_BUS=scsi

E: ID_PATH=pci-0000:00:10.0-scsi-0:0:2:0

[root@oel57 ~]# scsi_id -g -u -s /block/sdc/sdc1

[root@oel57 ~]# why nothing here???

 
 

Workaround:

Open file *.vmx of the virtual machine, add following:

# Parameters to enable UUID

disk.locking = “FALSE”

disk.EnableUUID = “TRUE”

 
Start the machine and run test again!
After:

[root@oel57 ~]# scsi_id -g -a -x -p 0x83 -s /block/sdc/sdc1

ID_VENDOR=VMware,

ID_MODEL=VMware_Virtual_S

ID_REVISION=1.0

ID_SERIAL=36000c29f3a2bebab3465f8e6ec1996dd

ID_TYPE=disk

ID_BUS=scsi

[root@oel57 ~]# udevinfo -q all -p /block/sdc/sdc1

P: /block/sdc/sdc1

N: sdc1

S: disk/by-id/scsi-36000c29f3a2bebab3465f8e6ec1996dd-part1

S: disk/by-path/pci-0000:00:10.0-scsi-0:0:2:0-part1

E: ID_VENDOR=VMware,

E: ID_MODEL=VMware_Virtual_S

E: ID_REVISION=1.0

E: ID_SERIAL=36000c29f3a2bebab3465f8e6ec1996dd

E: ID_TYPE=disk

E: ID_BUS=scsi

E: ID_PATH=pci-0000:00:10.0-scsi-0:0:2:0

[root@oel57 ~]# scsi_id -g -u -s /block/sdc/sdc1

36000c29f3a2bebab3465f8e6ec1996dd

[root@oel57 ~]#

Fix sharing violation errors in VMware Data Recovery -1020

We’ve deployed VMware Data Recovery in our live environment and have run into some issues with target devices being unavailable, generating sharing violation errors during backup.

There are no .lck files present and the target volume is exclusive to VDR.

A solution that seems to have done the trick, is tuning the Linux network stack (VDR is based on CentOS).

The default maximum TCP buffer size in Linux is too small for VDR to be happy. TCP memory is derived from the amount of system memory available. Usually the mem_max and wmem_max-values are set to 128Kb in most Linux distros, way too low a value for large chunks of data to be transferred efficiently.

SSH to your VDR appliance. Default username and password if unchanged is root and vmw@re.

We’ll start by setting wmem_max and rmem_max to 12Mb:

echo 'net.core.wmem_max=12582912' >> /etc/sysctl.conf
echo 'net.core.rmem_max=12582912' >> /etc/sysctl.conf

 

Proceed with minimum, initial and maximum size:

echo 'net.ipv4.tcp_rmem= 10240 87380 12582912' >> /etc/sysctl.conf
echo 'net.ipv4.tcp_wmem= 10240 87380 12582912' >> /etc/sysctl.conf

 

Window scaling will enlarge the transfer window:

echo 'net.ipv4.tcp_window_scaling = 1' >> /etc/sysctl.conf

 

Enable RFC1323 timestamps:

echo 'net.ipv4.tcp_timestamps = 1' >> /etc/sysctl.conf

 

Enable select acknowledgements:

echo 'net.ipv4.tcp_sack = 1' >> /etc/sysctl.conf

 

Disable TCP metrics cache:

echo 'net.ipv4.tcp_no_metrics_save = 1' >> /etc/sysctl.conf

 

Set max number of packets to be queued on the INPUT chain, if the interface receives packets faster than the kernel can manage:

echo 'net.core.netdev_max_backlog = 5000' >> /etc/sysctl.conf

 

Reload:

sysctl -p

VMWare network devices and udev

I’ve been struggling for a while trying to get udev to maintain device names for vmxnet devices when running in a virtual machine. Well, I finally figured it out. The 75-persistent-net-generator.rules script in Gentoo was making rules that looked like:

SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:0c:29:0b:02:d2", NAME="eth0"

These seemed to be silently ignored.

After an emerge --sync; emerge -u world last night, the vmware devices started getting IDs following the highest-numbered eth device. These rules would be added to 70-persistent-net.rules, and on the next boot the devices would move up even higher, causing all network device config settings to be ignored.

I noticed that the new rules added to 70-persistent-net.rules were of the form:

SUBSYSTEM=="net", DRIVERS=="?*", ATTR{address}=="00:0c:29:0b:02:d2", NAME="eth0"

(ATTRS was replaced with ATTR), which just means the match is done on the specific node rather than checking all of the parents.

After a lot of painful attempts to fix this, I finally found the problem. Apparently the DRIVERS key is unset at this point for the vmxnet driver. I removed that test, so that I have:

SUBSYSTEM=="net", ATTR{address}=="00:0c:29:0b:02:d2", NAME="eth0"

which now works.

Phew!