Questo post è disponibile anche in: Inglese

Reading Time: 4 minutes

A partire da vSphere 5, VMware raccomanda di usare come network virtual adapter la scheda di rete virtuale vmxnet3, ovviamente partendo da un virtual hardware almeno v7 e solo con sistemi operativi recenti, in pratica da Windows NT 6.0 (Vista o Windows Server 2008) e le varie distribuzioni Linux che includano già il driver della vmxnet3 all’interno del loro kernel.

Tipicamente per questi sistemi operativi la scelta è tra e1000 o vmxnet3: il wizard di creazione di una nuova VM già sceglie quello giusto per le distribuzioni Linux, mentre per i sistemi Windows si limita a proporre la e1000 solo perché il relativo driver è già incluso nell’immagine di installazione di Windows.

La verità è che non c’è una scheda migliore di un’altra, al di là degli aspetti legati alle prestazioni, tipicamente si cerca la massima stabilità e, purtroppo entrambe, hanno avuto vari problemi. Ma con vSphere 5 sembrava che i problemi della e1000 e i vantaggi della vmxnet3 portassero senza troppi dubbi la scelta sulla seconda. Purtroppo con vSphere 6 iniziano ad esservi troppi problemi legati alla vmxnet3.

Il problema più grave in assoluto è un PSOD bug che può colpire macchine virtuali con scheda vmxnet3 e virtual hardware 11, su host ESXi 6.0U2 (anche se, secondo me, non sono da escludere le versioni precedenti di vSphere 6.0). L’articolo di KB 2144968 (ESXi 6.0 Update 2 host fails with a purple diagnostic screen containing the error: Vmxnet3VMKDevRxWithLock and Vmxnet3VMKDevRx) spiega il problema e come possa causare il terribile purple screen sull’host che esegue quella VM (alla faccia dell’isolamento che le VM dovrebbero avere).

L’aspetto grave è che non esiste una vera e propria soluzione (né una data di rilascio della patch) e l’unico workaround suggerito è di disabilitare l’hardware LRO for VMXNET3 a livello di ESXi host:

  • To disable the hardware LRO on the ESXi host change the advanced configuration option /Net/Vmxnet3HwLRO to 0. For more information, see Configuring advanced options for ESXi/ESX (1038578)
    Note:

    • Software LRO is enabled for VMXNET3 when hardware LRO is disabled.
    • This also can be set with this esxcli command:esxcli system settings advanced set -o /Net/Vmxnet3HwLRO -i 0

In realtà l’articolo suggerisce anche il rollback ad una versione precedente, ma non sembra una gran soluzione visto gli altri problemi che affliggono le versioni precedenti di vSphere 6.0. A meno di tornare sulla 5.5 che invece non è affetta da questo problema.

Aggiornamento del 12 maggio 2016: VMware ha risolto questo problema con la patch descritta nella KB 2144685 (VMware ESXi 6.0, Patch ESXi600-201605401-BG: Updates esx-base, vsanhealth, vsan VIBs).

Ma oltre a questo grave problema vi sono alcune problematiche legate alla prestazioni della scheda vmxnet3 (che in teoria dovrebbe essere anche la più veloce) sia su sistemi operativi Linux che Windows.

Per Linux gli articoli KB 1027511 (Poor TCP performance might occur in Linux virtual machines with LRO enabled) e KB 2077393 (Poor network performance when using VMXNET3 adapter for routing in a Linux guest operating system) spiegano diverse problematiche. Curioso come alcuni di questi problemi erano già noti in passato e non è la prima volta che bug vecchi tornano in versioni recenti.

Per Windows, in realtà, in problema affligge solo Windows Server 2012, Windows 8 o successivi su VM con virtual hardware 11 e, naturalmente, scheda vmxnet3: l’articolo della VMware KB 2129176 (After upgrading a virtual machine to hardware version 11 network dependent workloads experience performance degradation) descrive il problema, la soluzione temporanea e afferma che il problema sia risolto nella ESXi 6.0 Update 2 (ma senza minimamente menzionare il grave problema del PSOD descritto in precedenza).

Curioso come in tutti i casi il workaround sia di disabilitare lato VM o lato host l’implementazione in hardware del Large Receive Offload (LRO) Support for VMXNET3 Adapters with Windows VMs on vSphere 6, a quanto pare non implementato così bene.

Per quanto riguarda la scelta dei virtual network adapter, vedere questi documenti (in inglese):

Andrea MauroAbout Andrea Mauro (2922 Posts)

Virtualization, Cloud and Storage Architect. Tech Field delegate. VMUG IT Co-Founder and board member. VMware VMTN Moderator and vExpert 2010-18. Dell TechCenter Rockstar 2014-15. Microsoft MVP 2014-16. Veeam Vanguard 2015-18. Nutanix NTC 2014-18. PernixPro 2014-16. Several certifications including: VCDX-DCV, VCP-DCV/DT/Cloud, VCAP-DCA/DCD/CIA/CID/DTA/DTD, MCSA, MCSE, MCITP, CCA, NPP.


Share