Teoricamente su un sistema UEFI il disco di installazione di Windows 7 dovrebbe installarsi automaticamente in modalità UEFI; praticamente è anche molto probabile che qualche baco nel BIOS pregiudichi questa possibilità.
A che serve lanciare l’installazione di Win7 in modalità UEFI? A poter installare il sistema su un disco partizionato GPT anziché MBR (necessario ad esempio per dischi >2 TiB).
Ho provato ad utilizzare una delle tantissime guide che spiegano come installare TianoCore (un emulatore UEFI) ma non sono arrivato da nessuna parte.
La soluzione che funziona è questa:
- scaricare oscdimg.exe (sarà parte di qualche DDK, WWF, ecc.)
- inserire il disco di installazione nel lettore DVD-ROM (supponiamo D:)
- lanciare da riga di comando:
oscdimg -w4 -os -lWin_7_x64_UEFI_ISO9660 -m -o -n -pEF –e
-bd:\efi\microsoft\boot\efisys.bin d:\ win7uefi.iso
Il risultato è un file ISO masterizzabile che, in presenza di una scheda madre che supporti UEFI, avvierà l’installazione in tale modalità senza passare dal BIOS.
-quack
Una delle migliori feature di Xen, secondo mio modesto parere, è il supporto di due tipi di virtualizzazione. Quella più tradizionale, vera e propria emulazione di una macchina fisica, e quella che viene definita para-virtualizzazione.
La para-virtualizzazione è una variante della virtualizzazione in cui il sistema operativo host espone delle periferiche virtuali e non emulate al sistema operativo guest, il cui kernel deve essere scritto in modo appropriato per gestire queste periferiche (in parole povere il kernel para-virtualizzato sa di avere a che fare ad esempio con una VCPU anziché un processore vero). Questo kernel modificato è disponibile in quasi tutte le distro Linux ed in generale con sistemi operativi Unix based (Solaris, BSD, etc.). La para-virtualizzazione pertanto non può essere usata per far girare dei guest Windows.
Una macchina virtuale in XEN non è altro che un file di configurazione che elenca le proprietà e le periferiche emulate/passate nella macchina virtuale. Il template da usare, per
device_model = '/usr/lib/xen/bin/qemu-dm'
kernel = '/usr/lib/xen/boot/hvmloader'
builder = 'hvm'
memory = 4096
name = 'vm_name'
vif = [
'type=ioemu, bridge=br0, mac=00:0b:27:1f:ed:75, model=e1000'
]
disk = [
'phy:/dev/disk/by-id/scsi-SATA_SAMSUNG_HM640,ioemu:hda,w',
'file:/xen/whs/install.iso,ioemu:hdc:cdrom,r'
]
pci = [
'00:1d.0', #front usb panel
]
boot = 'd'
vnc = 1
vncdisplay = 1
usb = 1
usbdevice = 'tablet'
vcpus = 4
localtime = 1
Le righe evidenziate sono quelle da modificare e che contengono il succo della configurazione della macchina virtuale.
Memory: quantità di RAM assegnata in MB
Name: nome della VM
Vif: contiene l’elenco delle schede di rete virtuali; è fondamentale settare correttamente il nome del bridge e creare un mac address ad hoc; se non si specifica il mac address ne verrà assegnato uno a caso diverso ad ogni avvio della macchina virtuale (Windows usa il mac address per l’attivazione)
Disk: l’elenco dei dischi fisici/virtuali da assegnare.
Pci: elenco delle schede PCI visibili al guest (richiede che il sistema supporti VT-d/IOMMU e che la scheda PCI sia sganciata dal sistema operativo host)
Vncdisplay: è la porta vnc da usare. 1 significa porta 5901, 2 significa 5902, ecc.
Vcpu: numero di CPU virtuali da assegnare
Prima di far partire la macchina virtuale bisogna però sganciare dal sistema host le periferiche PCI associate al guest. Per far ciò bisogna conoscere sia il PNP-id della periferica, sia l’indirizzo PCI associato.
Il secondo si ottiene usando il comando lspci che sul mio sistema sputa qualcosa del genere:
[…]
00:1d.0 USB Controller: Intel Series Chipset Family USB Enhanced
Host Controller #1
01:00.0 VGA compatible controller: [FirePro V5700]
01:00.1 Audio device: ATI Technologies Inc RV710/730
[…]
Per ottenere il PNP-id va usato la variante:
lspci -n
che restituisce nel caso in esempio:
00:1d.0 0c03: 8086:1c26 (rev 04)
01:00.0 0300: 1002:949e
01:00.1 0403: 1002:aa38
A questo punto si ha a disposizione sia il PCI-id sia il PNP-Id e si può chiedere all’host di sganciare la periferica con questa serie di comandi prontamente trascritta in un file .sh:
echo "8086 1c26" >/sys/bus/pci/drivers/pci-stub/new_id
echo "0000:00:1d.0" >/sys/bus/pci/devices/0000:00:1d.0/driver/unbind
echo "0000:00:1d.0" >/sys/bus/pci/drivers/pci-stub/bind
La macchina virtuale poi può essere fatta partire via terminale sudato con:
xm create nome-file-configurazione
Una volta partita ci si può collegare usando un qualsiasi client VNC usando l’indirizzo IP della macchina host e la porta specificata nel file di configurazione. Nel caso in esempio poi tutte le periferiche USB collegate al controller PCI verranno viste nativamente dal sistema operativo guest (nel mio caso una stampante e una scheda audio USB).
Il passthru della scheda grafica richiede qualche piccola operazione dal lato client: vanno dapprima installati i driver della scheda grafica “fisica” assegnata, che verrà prontamente rilevata e riconosciuta dal sistema operativo guest, e in seguito va disabilitata la scheda grafica emulata tramite device manager. A causa di qualche problema di instabilità, il file di configurazione di Windows 7 contiene queste ulteriori due righe:
timer_mode = 2
viridian = 1
Last but not least l’uso di driver para-virtualizzati (firmati) disponibili a questa pagina può portare a qualche interessante miglioramento in termini di prestazioni delle periferiche ‘emulate’ (scheda di rete e hard drive).
Sulla necessità della seconda non sono però molto sicuro. E questo è quanto è necessario per ottenere ‘o miracol di una workstation completamente virtualizzata
Il prossimo appuntamento sarà dedicato alla para-virtualizzazione di Solaris.
-quack
Cosa si può fare per trasformare il traffico su un ponte galleggiante di 640 metri da così:
a così:
?
Basta introdurre un pedaggio dal costo che va di un minimo di 1.60$ ad un massimo di 5.00$ per singola traversata (0.78 centesimi al metro, probabilmente tra i più cari del mondo). Il tutto per finanziare il nuovo progetto di allargamento dello stesso ponte. Il sistema di pedaggio automatico, tra i più avanzati al mondo, ha richiesto diverse iterazioni e rinvii ma è stato finalmente “battezzato” lo scorso 29 dicembre e compiva ieri il suo primo mese di vita.
La leggenda narra di colleghi in preda alla sindrome di astinenza da traffico che dichiarano di attraversare il ponte ad oltre 100mph (per intenderci altra leggenda narra che colti in fragrante oltre i 90mph ci sia l’arresto).
-quack
P.S. sono totalmente favorevole al sistema di tassazione “a consumo”, solo che per ovvie ragioni le tariffe parrebbero elevate. O si lascia intervenire la legge della domanda e dell’offerta oppure (molto più probabile) si introduce un pedaggio sul ponte cugino e parallelo.
Altre due parole sulla questione secure boot.
Riflettevo alla periodicità di certi allarmismi:
C’è stato allarmismo quando è stato imposto l’utilizzo di driver firmati per Windows x64.
C’è stato tantissimo allarmismo quando Windows Vista ha aggiunto il supporto al TPM.
Oggi c’è tantissimo allarmismo per l’introduzione del supporto, in alcuni casi obbligatorio, del secure boot.
In realtà da sempre l’introduzione di una nuova piattaforma (x64 allora, ARM oggi) è sempre occasione per ripensare a cosa si poteva fare meglio. I driver firmati sono un passo avanti a tanta robaccia che prima installava pezzi di codice in kernel mode. Ma il salto è stato possibile solo con il cambio di piattaforma in virtù delle qualità di backward compatibility dell’ecosistema Windows, qualità più uniche che rare.
Anche allora si gridava all’anatema: ma oggi, la mancanza di driver non firmati per WinX64 la sente davvero qualcuno?
-quack
Ingredienti fondamentali per riprodurre ‘o miracolo.
- Scheda madre Intel che supporti VT-d. Ci sono altri produttori che supportano VT-d nei loro modelli ma il tutto è abbastanza fumoso. La mia scelta è andata per una DQ67OW
- Processore compatibile VT-d. Ho scelto lo XEON E3-1260L per via della scheda grafica integrata, delle prestazioni (4 core, 8 thread) e dei consumi (45W TDP).
- Una sheda grafica supportata, la mia scelta è andata per una FirePro V5700 tra l’altro poco costosa a causa del crash da bitcoin mining (vedasi).
Il bios della scheda madre è alquanto antipatico ed oltre a quello non sono riuscito a configurare l’opzione di default di GRUB: cioé sono riuscito a impostarla, ma il bootloader semplicemente la ignora, per cui ho scelto la via più semplice. Installare GRUB su una chiavetta USB e fare il boot da quella.
Dei tre componenti HW quello più delicato sembra essere la scheda grafica: la percentuale di successo con schede grafiche NVidia o non FirePro è decisamente bassa mentre la V5700 è indicata tra le schede testate (e spero supportate).
Dopo di che ho installato Fedora 16 in versione x64.
Xen si installa via terminale sudato con
yum install xen
Fin qui la parte facile, descritta anche in questa pagina Wiki.
Più complicato è stato creare il network bridge necessario per la connettività dei vari sistemi virtualizzati. Le istruzioni della pagina Wiki di cui sopra a tal riguardo sono incomplete. Nella directory /etc/sysconfig/network-scripts vanno creati due file.
File ifcfg-br0:
DEVICE=br0
TYPE=Bridge
BOOTPROTO=dhcp
ONBOOT=yes
DELAY=0
NM_CONTROLLED=NO
File ifcfg-em1:
DEVICE=em1
TYPE=Ethernet
ONBOOT=yes
BOOTPROTO=dhcp
NM_CONTROLLED=NO
BRIDGE=br0
Per chi vuole spolparsi il manuale, la documentazione riguardo questi interface configuration files è linkata qui. Il nome del bridge (nel caso di cui sopra è br0) è importante per la configurazione delle macchine (para)virtuali. Dopo di che va disabilitato il servizio NetworkManager (che non supporta i bridge) e abilitato il servizio network al suo posto:
systemctl disable NetworkManager.service
systemctl stop NetworkManager.service
systemctl enable network.service
systemctl start network.service
Come ultima fase del setup iniziale ho creato un folder /xen e ho abilitato la condivisione dei file via SMB usando le istruzioni che ho trovato qui.
Ho creato una nuova installazione di grub su chiavetta USB usando:
grub2-install --force --no-floppy --root-directory=/mnt/USB /dev/sdx
laddove /mnt/USB è la directory su cui è montata la chiavetta USB e /dev/sdx è il file associato al dispositivo che si ottiene usando il comando lsscsi. Ho poi copiato e alleggerito il file di configurazione grub da /boot/grub2/grub.cfg a /mnt/USB/boot/grub2/grub.cfg.
Il passo successivo è la creazione di macchine virtuali.
