Hyper-v: dischi virtuali IDE o SCSI?

Technorati Tags: Microsoft,Windows,Virtualization,Hyper-V

Ultimamente è nato in rete un dibattito relativo a come Hyper-V implementa i sottosistemi disco IDE e SCSI e quale sia migliore da un punto di vista delle performance.

Lo spunto nasce da quest'articolo di Tony Voellm (Microsoft) poi ripreso da Alessandro Perilli sul suo blog.

L'articolo di Tony afferma principalmente due cose:

  1. Le macchine virtuali, in Hyper-V, non potranno usare usare dischi virtuali SCSI per fare boot (attenzione che parliamo di dischi virtuali! I file VHD possono invece essere tranquillamente ospitati su dischi SCSI, su NAS, SAN, ecc...)
  2. I controller IDE, in Hyper-V, sono di tipo emulato (full virtualization) e quindi necessariamente più lenti dei controller SCSI che sono invece di tipo sintetico e quindi usano VSC-VMBUS-VSV per accedere ai dischi fisici, risultando più veloci

Da queste due affermazioni Alessandro Perilli deduce la necessità di avere due dischi virtuali per ogni macchina virtuale: un disco IDE per il boot e uno SCSI per accedere ai dati con ottime performance. Sempre secondo Alessandro Perilli, questo rende complessa la gestione delle macchine virtuali in Hyper-V soprattutto in scenari di migrazione fisico-virtuale.

Alessandro Perilli avrebbe ragione, se le premesse fossero completamente giuste, ma così non è.

Ritorniamo alle affermazioni di Tony Voellm.

  1. La prima è certamente vera: non essendoci, nel BIOS delle macchine virtuali, supporto per il bus SCSI virtuale i dischi di questo tipo sono visibili solo dopo il boot
  2. la seconda è vera, ma incompleta non tenendo in alcun conto gli Integration Components. Anche Tony Voellm si è accorto di questa mancanza e, in un successivo post, molto correttamente inserisce nello scenario gli Integration Components.

In che modo gli Integration Components entrano in gioco per migliorare le performance dei controller virtuali IDE?

In assenza degli Integration Components, come detto, il controller IDE è  completamente emulato (elevata compatibilità, basse performance).

Installando gli Integration Components viene installato, nello stack di I/O su disco, un filter driver (StorFlt.sys) che è in grado aggirare il percorso di I/O dell'emulazione e di sfruttare il VMBUS fornendo prestazioni assolutamente paragonabili (a parità di altre condizioni) a quelle dei dischi virtuali SCSI (era già possibile trovare questa informazione in un mio post del 21 maggio 2007 :) ). Il filter driver trasforma di fatto il driver IDE in un driver sintetico. Si possono, al massimo, avere durante le prime fasi di boot della macchina virtuale, prestazioni leggermente inferiori rispetto a quello che si hanno a boot completato (ossia dopo il caricamento del filter driver).

FilterDriver 
Filter driver per controller IDE in un child partition

FilterDriver-DataPath
Percorso dati per dischi IDE con gli Integration Components installati

E' da sottolineare che non è data la possibilità di avere dischi virtuali SCSI e in contemporanea dischi virtuali IDE senza il filter driver.

Quindi, riassumendo:

  1. i dischi virtuali IDE emulati sono più lenti dei dischi virtuali SCSI o IDE con filter driver
  2. è possibile fare boot solo da dischi IDE (Compatibili 48-bit LBA, in Hyper-V)
  3. è necessario installare gli Integration Components per poter usare dischi virtuali SCSI
  4. installando gli Integration Components si installa automaticamente il filter driver ottenendo sostanzialmente le stesse prestazioni per i dischi virtuali IDE e SCSI
  5. in fase di migrazione da fisico a virtuale sarà comunque necessario sostituire i device driver del controller disco fisico con quelli del controller disco virtuale. Se il sistema operativo installato nel server da virtualizzare è tra quelli per cui esistono gli Integration Components sarà possibile i dischi IDE con filter driver: non è necessario avere due tipi di dischi diversi!

Allora perché usare i dischi virtuali SCSI?

Per esempio perché ad ogni controller virtuale SCSI è possibile collegare fino a 255 dischi o un disco pass-through.

Per approfondire:

A presto

Giorgio