#format wiki #LANGUAGE it <
> <> <> <> = Introduzione = Questa pagina raccoglie risposte a domande frequenti relative a [[Virtualizzazione/Kvm|KVM]] in ambienti Ubuntu moderni (22.04 e successivi). Alcune sezioni potrebbero trattare argomenti di interesse storico o specifico per sistemi operativi guest meno recenti. = Gestione dei conflitti con altri hypervisor (VirtualBox) = '''[[Virtualizzazione/Kvm|KVM]]''', come altri hypervisor quali '''[[Virtualizzazione/VirtualBox|VirtualBox]]''', richiede l'accesso esclusivo alle estensioni di virtualizzazione hardware (Intel VT-x/AMD-V) del processore. Questo significa che solo un hypervisor può utilizzare queste estensioni in un dato momento. Se i moduli KVM sono caricati e in uso (anche senza VM attive), altri hypervisor potrebbero non riuscire ad avviarsi in modalità virtualizzazione hardware. * Per prevenire conflitti con VirtualBox o altri hypervisor che richiedono l'accesso esclusivo all'hardware di virtualizzazione: 0. Assicurarsi che tutte le macchine virtuali KVM siano spente. È consigliabile farlo tramite '''virt-manager''' o '''virsh shutdown '''. 0. Fermare il servizio '''libvirtd'''. Questo è il demone che gestisce le macchine virtuali KVM e che spesso mantiene i moduli KVM caricati. {{{ sudo systemctl stop libvirtd }}} 0. Scaricare i moduli del kernel KVM. Dopo aver fermato '''libvirtd''' e assicurandosi che nessuna VirtualMachine KVM sia in esecuzione (anche avviata direttamente con '''qemu-system-x86_64'''), è possibile tentare di rimuovere i moduli KVM dal kernel. Questo libera le estensioni hardware di virtualizzazione. {{{ sudo modprobe -r kvm_intel kvm_amd kvm }}}Una volta che i moduli KVM sono stati scaricati con successo, è possibile avviare VirtualBox o un altro hypervisor. {{{#!wiki note Questo comando potrebbe restituire un errore come "modprobe: FATAL: Module kvm is in use" se i moduli sono ancora in uso da qualche processo residuo. In tal caso, potrebbe essere necessario identificare e terminare il processo o, come ultima risorsa, riavviare il sistema. }}} * Per ripristinare KVM e libvirtd dopo aver utilizzato un altro hypervisor: 0. Avviare il servizio libvirtd: {{{ sudo systemctl start libvirtd }}}Questo ricaricherà automaticamente i moduli KVM necessari (ad esempio kvm_intel o kvm_amd, e kvm) e riabiliterà la gestione delle VM KVM. = Avvio di una macchina virtuale con accesso al BIOS o GRUB = Una macchina virtuale ha un BIOS/UEFI completo e può eseguire GRUB. Talvolta, la finestra della VM appare dopo che il BIOS o il menù di GRUB sono già scomparsi. La soluzione per assicurarsi di avere tempo per interagire con il BIOS o GRUB è: 0. Spegnere la macchina virtuale. 0. Eseguire '''virt-viewer''' con l'argomento '''--wait''':{{{ virt-viewer --wait }}}In questo modo, virt-viewer attenderà l'avvio della macchina virtuale e la sua finestra apparirà immediatamente non appena la VM inizia il boot. 0. Avviare la macchina virtuale. Questo approccio dovrebbe fornire il tempo necessario per interagire con il BIOS/UEFI (solitamente premendo Canc o F2 all'avvio) o con GRUB. Se si sta utilizzando una macchina virtuale creata con strumenti specifici o configurazioni meno recenti, e si riscontrano problemi di autenticazione o avvio, un metodo generico per accedere a una shell di ripristino (tipicamente per sistemi Linux) è: 0. Nel menù di [[AmministrazioneSistema/Grub|GRUB]], selezionare la linea per il ripristino («recovery mode») e premere '''e''' per modificare. 0. Selezionare la linea che inizia con «linux» o «kernel» e premere ancora '''e'''. 0. Aggiungere alla fine della linea «init=/bin/sh». 0. Confermare con '''Invio''' e premere '''b''' (o F10 a seconda della versione di GRUB) per avviare il kernel con queste impostazioni. Questo fornisce una shell root senza autenticazione per la risoluzione dei problemi. Questa procedura è generica per Linux e non legata a bug specifici di ubuntu-vm-builder. <> = Conversione di macchine VMWare a virt-manager = Per gestire una macchina virtuale '''VMWare''' con '''virt-manager''', il suo file .vmx può essere convertito in un file .xml compatibile con '''libvirt'''. Lo strumento '''vmware2libvirt''' è stato creato per facilitare questo compito ed è incluso nel pacchetto '''virt-goodies'''. 0. [[AmministrazioneSistema/InstallareProgrammi|Installare]] il pacchetto: [[apt://virt-goodies | virt-goodies]]. 0. Digitare in un [[AmministrazioneSistema/Terminale|terminale]] il seguente comando per convertire il file .vmx in un file .xml per libvirt:{{{ vmware2libvirt -f ./file.vmx > file.xml }}} {{{#!wiki note Per maggiori informazioni su vmware2libvirt, digitare:{{{ man vmware2libvirt }}} 0. [[ivantu/Virtualizzazione/Kvm/GestioneOspiti#Definizione_della_nuova_Macchina_Virtuale|Definirlo]], importare il file .xml in '''libvirt'''. Il file .xml importato viene memorizzato in /etc/libvirt/qemu:{{{ virsh -c qemu:///system define file.xml }}} == Considerazioni sulla conversione == Anche se '''vmware2libvirt''' funziona bene su macchine virtuali semplici, sussistono alcune limitazioni dovute sia al fatto che i file .vmx non contengono tutte le informazioni necessarie per una conversione perfetta, sia al fatto che '''vmware2libvirt''' non analizza a fondo tutte quelle che trova. Alcuni aspetti da verificare dopo la conversione: 0. Anche se '''vmware2libvirt''' rileva un ospite a 64-bit, è necessario verificare che la corretta architettura sia stata riportata nel suo file .xml. Assicurarsi che la sezione sia simile a:{{{ hvm ... }}} 0. '''vmware2libvirt''' rileva e configura solamente la prima interfaccia ethernet trovata. Ulteriori interfacce devono essere aggiunte manualmente tramite '''virt-manager''' o modificando il file XML. 0. Attualmente, lo strumento configura il primo disco SCSI se trovato, altrimenti il primo disco IDE. Ulteriori dischi possono essere aggiunti tramite '''virt-manager''' o modificando il file XML. 0. La macchina virtuale convertita è impostata all'uso di 1 sola CPU. Per modificarlo, editare il file XML e impostare il numero desiderato (es. 2):{{{ 2 }}} 0. '''vmware2libvirt''' non converte tutte le configurazioni specifiche di '''VMWare''' all'interno dell'ospite (es. VMWare Tools). == Uso e conversione di file su disco virtuale VMWare == '''KVM''' è in grado di utilizzare direttamente i file .vmdk di '''VMWare''' come dischi virtuali, a condizione che il disco sia interamente contenuto in un singolo file .vmdk (formato "monolithic flat" o "monolithic sparse"). Se '''VMWare''' ha suddiviso il disco in più file .vmdk più piccoli (solitamente da 2 GB), '''KVM''' non potrà usarli direttamente. In quest'ultimo caso, è necessario riunire i file `.vmdk` in un unico file. Questo può essere fatto utilizzando '''vmware-vdiskmanager''', uno strumento incluso in '''VMWare Workstation''' o '''VMWare Server''' (precedentemente distribuito gratuitamente):{{{ vmware-vdiskmanager -r -t 0 }}} Una volta ottenuto un singolo file .vmdk, è possibile configurarlo nel file .xml della macchina virtuale in /etc/libvirt/qemu o tramite virt-manager. Esempio di configurazione XML:{{{ ... ... }}}Quindi ridefinire la macchina virtuale:{{{ virsh -c qemu:///system define Nome_della_macchina.xml }}} {{{#!wiki note Ricordare che finché il file `.vmx` è convertito in `.xml`, i dischi saranno usati in questo modo. Si consiglia di fare dei backup, specialmente se si prevede un utilizzo successivo della macchina virtuale in '''VMWare'''. }}} Per sfruttare appieno le funzionalità avanzate di QEMU/KVM, come gli snapshot basati sul formato di immagine, si consiglia di convertire il file .vmdk nel formato qcow2 di QEMU. Questo può essere fatto con l'utility '''qemu-img''', inclusa nel pacchetto qemu-utils:{{{ qemu-img convert nomedisco.vmdk -O qcow2 nomedisco.qcow2 }}}Dopo la conversione, modificare il file .xml della macchina virtuale per puntare al nuovo file .qcow2 e ridefinirla. == Recupero degli strumenti di VMWare dopo la conversione == Dopo la conversione di una macchina virtuale da '''VMWare''' a '''libvirt''' (KVM/QEMU), è importante rimuovere i ''VMWare Tools'' se installati nel sistema operativo guest. In caso contrario, questi strumenti potrebbero causare problemi (es. sovrascrittura di xorg.conf per i guest Linux) o conflitti con i driver e agent QEMU/KVM. == Conversione di macchine fisiche a virt-manager == Per convertire una macchina fisica Windows (in particolare versioni più vecchie come Windows XP) in una macchina virtuale KVM, è spesso necessario abilitare i driver IDE nei registri di Windows prima della conversione, per evitare schermate blu all'avvio della VM. {{{#!wiki note Vedere anche [[http://support.microsoft.com/kb/314082/en-us|l'articolo della Microsoft Knowledge Base 314082]] per ulteriori informazioni su questo problema. }}} == Utilizzo di VMWare Converter == '''VMWare Converter''' è uno strumento gratuito e ben noto per migrare una macchina fisica in un'immagine virtuale VMWare (P2V - Physical To Virtual). Il primo passo consiste nel convertire la macchina fisica in un'immagine '''VMWare'''. Successivamente, seguire le istruzioni nel paragrafo [[#ConversionedimacchineVMWareavirt-manager|Conversione di macchine VMWare a virt-manager]] per importare l'immagine VMWare in KVM/libvirt. == Utilizzo di strumenti Linux per P2V == Per la conversione di macchine fisiche a virtuali (P2V) su Linux, si possono consultare risorse esterne specializzate. Ad esempio, il libro tedesco su '''QEMU''' menziona strategie per il "physical to virtual". Cercare la sezione "physical to virtual" in [[http://qemu-buch.de/de/index.php/QEMU-KVM-Buch/_Speichermedien/_Physical-to-Virtual|questa risorsa]] (selezionare il link '''English''' per la traduzione). = Sincronizzazione dell'ora nelle macchine virtuali = Le macchine virtuali KVM moderne possono e dovrebbero utilizzare protocolli standard come '''[[Server/SincronizzazioneTempoNtp|NTP (Network Time Protocol)]]''' o '''systemd-timesyncd''' (nei guest Linux) per mantenere l'ora sincronizzata, esattamente come farebbe una macchina fisica. Non è necessario rimuovere o disabilitare '''ntpd''' o servizi simili nel guest. L'hypervisor fornisce un orologio hardware virtuale (RTC) che il sistema guest usa come base, e il software di sincronizzazione dell'ora nel guest si occuperà di eventuali derive. Per una migliore precisione, è consigliato che il guest esegua il suo servizio NTP. = Driver video per Xorg nei sistemi guest Linux = {{{#!wiki note Per le massime prestazioni e funzionalità moderne (come il supporto 3D e la risoluzione dinamica) nei sistemi guest Linux su KVM, si raccomanda caldamente l'uso del driver '''virtio-gpu''' con '''virglrenderer'''. }}} === Driver legacy === Durante la prima installazione di un ospite Linux, o per la massima compatibilità, si possono utilizzare driver video generici: * '''cirrus''': driver molto semplice e compatibile, ma con risoluzioni limitate. * '''vesa''' (o '''std'''): offre risoluzioni maggiori (fino a 1600x1200) rispetto a cirrus, ma con funzionalità grafiche base. In generale, i sistemi Linux moderni configurano automaticamente i driver Xorg e non richiedono un file xorg.conf manuale. Tuttavia, se si necessita di forzare una configurazione specifica o si usano driver non autodetect, un file xorg.conf potrebbe essere creato. Quindi per poter usare i driver '''standard''' procedere come segue: Un esempio di xorg.conf per i driver vesa (o std) in un guest KVM, che permette risoluzioni superiori a 800x600. * Aprire con un [[Ufficio/EditorDiTesto|editor di testo]] il file `/etc/X11/xorg.conf`:{{{ Section "ServerLayout" Identifier "KVM xorg.conf" Screen 0 "Screen0" 0 0 InputDevice "Mouse0" "CorePointer" InputDevice "Keyboard0" "CoreKeyboard" EndSection Section "Module" Load "record" Load "dri" Load "extmod" Load "glx" Load "dbe" Load "dri2" EndSection Section "InputDevice" Identifier "Keyboard0" Driver "kbd" EndSection Section "InputDevice" Identifier "Mouse0" # Per mouse PS/2 emulato, usare 'vmmouse'. Per virtio-input, non è necessario un driver specifico xorg. Driver "vmmouse" Option "Protocol" "SysMouse" Option "Device" "/dev/sysmouse" Option "ZAxisMapping" "4 5 6 7" EndSection Section "Monitor" Identifier "Monitor0" VendorName "Virtual Monitor" ModelName "KVM Monitor" HorizSync 20.0 - 50.0 VertRefresh 40.0 - 80.0 Option "DPMS" EndSection Section "Device" Identifier "Card0" Driver "vesa" VendorName "QEMU/KVM" BoardName "Standard VGA" BusID "PCI:0:2:0" EndSection Section "Screen" Identifier "Screen0" Device "Card0" Monitor "Monitor0" SubSection "Display" Viewport 0 0 Modes "1600x1200" "1024x768" "800x600" EndSubSection EndSection }}}Per modificare la risoluzione, è possibile cambiare i valori all'interno della linea «Modes». === Configurazione del driver video nella VM === La configurazione del driver video per un guest KVM varia a seconda dello strumento utilizzato per gestire la VM: * '''Linea di comando (qemu-system-x86_64)''' Per utilizzare il driver std (standard VGA), usare l'opzione -vga std:{{{ qemu-system-x86_64 -hda ubuntu.qcow -vga std }}}Per virtio-gpu (raccomandato), si userebbe:{{{ qemu-system-x86_64 -hda ubuntu.qcow -vga virtio -display sdl,gl=on }}} {{{#!wiki note L'opzione -display sdl,gl=on abilita il rendering OpenGL con virglrenderer se supportato dall'host e dal guest). }}} * '''Virt-manager''' Ad ospite spento, accedere alle impostazioni hardware della VM. Nella sezione ''Video'', selezionare il modello desiderato (es. ''QXL'' o ''virtio''). Per virtio-gpu è spesso necessario assicurarsi che sia presente anche il supporto 3D (selezionando la casella appropriata se disponibile nell'interfaccia). * '''Libvirt (file XML)''' * Modificare il file XML dell'ospite per impostare il modello video. Per un driver standard (VGA): {{{ }}}Per QXL (buone prestazioni, richiesto spice-vdagent nel guest):{{{ }}}Per virtio-gpu (raccomandato per Linux guest moderni, per prestazioni ottimali e 3D con virglrenderer):{{{ }}}I driver del mouse vmmouse sono presenti nella maggior parte delle distribuzioni Linux, ma per una migliore integrazione e funzionalità come il puntatore automatico, è raccomandato installare i qemu-guest-agent e usare virtio-input (spesso implicito con virtio-gpu). = Impostazione della risoluzione del guest in Linux (con driver legacy) = Nell'eventualità che si stiano usando driver video legacy (es. vesa) in un guest Linux e un '''xorg.conf''' manuale, per variare la risoluzione è sufficiente editare il file xorg.conf modificando i valori nella linea Modes. In alternativa, in modalità grafica, le impostazioni di risoluzione sono gestite dal desktop environment: * In [[AmbienteGrafico/Gnome|Gnome]]: Sistema → Preferenze → Monitor (o Impostazioni → Schermi). * In [[AmbienteGrafico/Xfce|XFCE]]: Applicazioni → Impostazioni → Display. {{{#!wiki note Con il driver virtio-gpu (raccomandato), la risoluzione è solitamente gestita in modo dinamico e automatico dal desktop environment del guest, rendendo le modifiche manuali a xorg.conf superflue. }}} = Impostazioni raccomandate per specifici sistemi guest = == Windows XP / Vista (e precedenti) == Per alcune versioni di Windows più vecchie (pre-Windows 7), la configurazione ACPI predefinita di KVM/QEMU potrebbe causare problemi. Se si riscontrano instabilità, provare a modificare la sezione nel file .xml della VM. * Per Windows XP (e precedenti), se si hanno problemi con ACPI, provare a rimuovere o :{{{ }}} * Per Windows Vista, in alcuni casi l'aggiunta esplicita di ACPI può migliorare la stabilità (se non già presente):{{{ ... }}}Si consiglia di verificare la documentazione specifica per la versione di Windows in uso e per la versione di QEMU/KVM. == OpenBSD (versioni legacy) == Questa sezione è obsoleta per le versioni moderne di OpenBSD. I problemi con driver di rete rtl8139 e watchdog timeout (per OpenBSD 4.1) o blocchi al boot (per OpenBSD 4.5) sono specifici di versioni molto vecchie. Per le versioni moderne di OpenBSD su KVM, è fortemente raccomandato l'uso dei driver virtio (NIC, disco, ecc.) per prestazioni e stabilità ottimali. = Ulteriori risorse = * [[https://help.ubuntu.com/community/KVM/FAQ|Documento originale]] (potrebbe contenere informazioni obsolete) ---- CategoryHomepage CategoryNuoviDocumenti