Differenze tra le versioni 1 e 35 (in 34 versioni)

Indice

Introduzione
Gestione conflitti con altri hypervisor
1. Prevenire conflitti con altri hypervisor
2. Ripristinare KVM
Avvio VM con accesso al BIOS o GRUB
Sincronizzazione ora
Driver video per Xorg nei sistemi guest Linux
1. Driver legacy
2. Configurazione driver video VM
Impostazione risoluzione guest con driver legacy
Impostazioni raccomandate per specifici sistemi guest
1. Windows XP/Vista (e precedenti)
2. OpenBSD (versioni legacy)
Ulteriori risorse

Guida verificata con Ubuntu: 22.04 24.04 25.04 25.10

Problemi in questa pagina? Segnalali in questa discussione

Introduzione

Questa pagina raccoglie risposte a domande frequenti relative a 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 conflitti con altri hypervisor

KVM, come altri hypervisor quali 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.

Prevenire conflitti con altri hypervisor

Assicurarsi che tutte le macchine virtuali KVM siano spente. È consigliabile farlo tramite virt-manager oppure comando:
```
virsh shutdown NOME_VM`
```
Fermare il servizio libvirtd. Questo è il demone che gestisce le macchine virtuali KVM e che spesso mantiene i relativi moduli caricati.
```
sudo systemctl stop libvirtd
```
Rimuovere i moduli KVM del kernel. Dopo aver fermato libvirtd e assicurandosi che nessuna macchina virtuale KVM sia in esecuzione (anche avviata direttamente con qemu-system-x86_64), è possibile tentare di rimuovere i moduli per liberare le estensioni hardware di virtualizzazione.
```
sudo modprobe -r kvm_intel kvm_amd kvm
```
Una volta che i moduli KVM sono stati rimossi con successo è possibile avviare VirtualBox o altro hypervisor.
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 oppure come ultima risorsa riavviare il sistema.

Ripristinare KVM

Per ripristinare KVM dopo aver utilizzato un altro hypervisor è sufficiente avviare il servizio libvirtd:
```
sudo systemctl start libvirtd
```
Questo ricaricherà automaticamente i moduli KVM necessari (ad esempio kvm, kvm_intel o kvm_amd) e riabiliterà la gestione delle VM KVM.

Avvio VM 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. Per assicurarsi di avere il tempo sufficiente per interagire con il BIOS o GRUB :

spegnere la macchina virtuale.
Eseguire virt-viewer con l'argomento --wait:
```
virt-viewer --wait NOME_VM
```
In questo modo virt-viewer attenderà l'avvio della macchina virtuale e la sua finestra apparirà non appena la VM inizia il boot.
Avviare la macchina virtuale. Dovrebbe esserci il tempo sufficiente per poter interagire con il BIOS/UEFI, (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 è:

selezionare nel menù GRUB la linea per il ripristino recovery mode e premere e per modificare.
Selezionare la linea che inizia con linux o kernel e premere ancora e.
Aggiungere alla fine della linea init=/bin/sh
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.

Sincronizzazione ora

Le macchine virtuali KVM moderne possono e dovrebbero utilizzare protocolli standard come 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

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'utilizzo 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 utilizzare 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 i privilegi di amministrazione e un 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 alla voce Modes.

Configurazione driver video 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
```
L'opzione -display sdl,gl=on abilita il rendering OpenGL con virglrenderer se supportato dall'host e dal guest).

Virt-manager

A 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:

<model type='vga' vram='9216' heads='1'/>

Per QXL (buone prestazioni, richiesto spice-vdagent nel guest):
```
<model type='qxl' vram='65536' heads='1'/>
```
Per virtio-gpu (raccomandato per Linux guest moderni, per prestazioni ottimali e 3D con virglrenderer):
```
<model type='virtio' heads='1' primary='yes'>
<acceleration accel3d='yes' accel2d='yes'/>
</model>
```
I driver del mouse vmmouse sono presenti nella maggior parte delle distribuzioni Linux, ma per una migliore integrazione efunzionalità come il puntatore automatico, è raccomandato installare i qemu-guest-agent e usare virtio-input (spesso implicito con virtio-gpu).

Impostazione risoluzione guest con driver legacy

Nell'eventualità che si stiano utilizzando 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 del parametro Modes.

In alternativa, in modalità grafica, le impostazioni di risoluzione sono gestite dal desktop environment:

In Gnome: Sistema → Preferenze → Monitor (o Impostazioni → Schermi).
In XFCE: Applicazioni → Impostazioni → Display.

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 <features> nel file .xml della VM.

Per Windows XP (e precedenti), se si hanno problemi con ACPI, provare a rimuovere <acpi/> o <apic/> nella sezione <features>.
Per Windows Vista, in alcuni casi l'aggiunta esplicita di ACPI può migliorare la stabilità (se non già presente):
```
<domain type='kvm'>
...
<features>
<acpi/>
</features>
</domain>
```
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

Documento originale (potrebbe contenere informazioni obsolete)

CategoryVirtualizzazione

-  ⇤ ← Versione 1 del 22/03/2010 22.29.12 → 
  Dimensione: 10085
  Autore: FabioMarconi
  Commento:
+   ← Versione 35 del 25/10/2025 11.16.54 → ⇥
  Dimensione: 11295
  Autore: jeremie2
  Commento: revisione - spostata sezione "Conversione macchine" nella pagina  Virtualizzazione/Kvm/ConversioneMacchine
-Le cancellazioni sono segnalate in questo modo.
+Le aggiunte sono segnalate in questo modo.
 Linea 1:
-#title KVM FAQ
<<Include(KVM/Header)>>
||<tablestyle="float:right; font-size: 0.9em; width:30%; background:#F1F1ED; margin: 0 0 1em 1em;" style="padding:0.5em;"><<TableOfContents(3)>>||

= Frequently Asked Questions =

== How to prevent Virtualbox and KVM from conflicting? ==
Installing kvm loads the module kvm (or kvm-intel in my case) which does not allow other virtualization software to run, e.g. virtualbox.

The good news is that you ''can'' disable kvm and unload its modules. So you simply:

1. Make sure you've completely shut down and powered off all your kvm virtual machines (using virt-manager or otherwise).

2. Unload all of its modules:
{{{
$ sudo invoke-rc.d kvm stop
}}}
In Karmic use
{{{
$ sudo invoke-rc.d qemu-kvm stop
}}}
instead.

== How to boot Dapper, Edgy, Feisty or Gutsy ISO? ==

 * Q: I'm on Intel hardware, and I'm trying to boot Dapper, Edgy, Feisty, or Gutsy, but kvm fails immediately.
 * A: Yes, this is rather unfortunate. The issue is a limitation in Intel's virtualisation extensions that don't interact very well with gfxboot. The evil, hacky workaround is to modify the ISO to disable gfxboot. The following has worked for me, but it might kill your cat or make your coffee go cold or make other unpleasantries happen to you. You've been warned!
{{{
$ sed -e 's/GFXBOOT bootlogo/#FXBOOT bootlogo/g' < ubuntu-7.10-server-amd64.iso > ubuntu-7.10-server-amd64-nogfxboot.iso
}}}
/!\ Don't change the above command! The length of the string mustn't change or you will have knackered the filesystem on the CD.

A slightly safer way is to download gfxboot-disable from [[http://hg.codemonkey.ws/gfxboot-disable]] and then run:
{{{
$ gfxboot-disable ubuntu-7.10-server-amd64.iso
}}}

== How to boot a VM into single mode? ==

A VM has a complete BIOS, and also runs GRUB. Bad point is, it disappears after a couple of seconds, most of the time you won't even have time to connect using virt-viewer. There is a small trick here: shutdown the VM, run virt-viewer with the argument --wait (that way it will wait for the VM to start and pop up directly after that), and then start the VM; this should give you a good 2 seconds time to enter the bios or access grub.

If you are running a VM built with ubuntu-vm-builder, there is a small bug that will prevent you from logging in; in grub, select the recovery line and press "e"; select the line beginning with kernel, press "e" again. At the end of the line, add "init=/bin/sh" (without the quotes). Confirm with enter, and press b to boot the kernel with these settings.

== How to convert VMware machines to virt-manager? ==

To use the VMware machine from within virt-manager, the .vmx file must be converted to libvirt's .xml. vmware2libvirt was created to help with this. It's available in Intrepid/Jaunty, install package 'virt-goodies'. After installing it can be used like so:
{{{
$ vmware2libvirt -f ./file.vmx > file.xml
$ virsh -c qemu:///system define file.xml
}}}

The first command converts the VMware 'file.vmx' file to the libvirt compatible 'file.xml'. See {{{ man vmware2libvirt }}} for details. The second command imports file.xml into libvirt. The imported .xml files are stored in /etc/libvirt/qemu.

=== Caveats ===
 While vmware2libvirt works well on simple virtual machines, there are limitations because .vmx files don't always contain enough information, and also because vmware2libvirt tries not to make too many assumptions about what it finds. A couple of things to look out for:
  0. While vmware2libvirt attempts to detect a 64-bit guest, be sure that your 64-bit guest has in its .xml file: {{{
<os>
 <type arch='x86_64' machine='pc'>hvm</type>
 ...
</os>
}}}
  0. vmware2libvirt only detects and uses the first ethernet interface found. Additional interfaces can be added from within virt-manager.
  0. Currently the first scsi disk is used if found, otherwise the first ide disk. Additional disks can be added from within virt-manager.
  0. The converted virtual machine is hard-coded to use 1 cpu.  This can be changed with:{{{
<vcpu>2</vcpu>
}}}
  0. vmware2libvirt does not (and cannot) convert anything that was VMware-specific within the guest. See 'Guest Notes' below for more details.

=== Using and Converting VMWar'e virtual Disk Files ===

kvm has the ability to use VMWare's .vmdk disk files directly, as long as the disk is wholly contained in a single vmdk file.

But VMWare also allows splitting a disk into smaller, usually 2 GB, vmdk files. kvm can't use these. You can convert these files into a single virtual disk file using vmware-vdiskmanager. It is e.g. included in VMWare Server (freely available).

{{{
$ vmware-vdiskmanager -r <Name of splitted vmdk base file> -t 0 <Name of new single vmdk file>
}}}

Modify the virtual machines xml file in /etc/libvirt/qemu:

{{{
 ...
 <disk type='file' device='disk'>
      <source file='/var/lib/libvirt/images/diskname.vmdk'/>
      <target dev='hda' bus='ide'/>
 </disk>
 ...
}}}

and redefine it: 

{{{
$ virsh -c qemu:///system define NameOfMachine.xml
}}}

'''IMPORTANT:''' keep in mind that while the .vmx file is converted to .xml, the disks are used as is. Please make backups, especially if you want to use the virtual machine in VMWare later.

kvm is not able to make snapshots when using vmdk disk files. So I recommend to convert the virtual disk file in qemu's format qcow2. Package qemu contains a utility qemu-img to do this:

{{{
qemu-img convert diskname.vmdk -O qcow2 diskname.qcow2
}}}

change the machines xml file and redefine it (see above). 



=== Should VMWare Tools be kept after conversion? ===

If converting from vmware to libvirt, be sure to remove vmware-tools if you have it installed (otherwise it will overwrite xorg.conf on reboot)

== How to convert physical Machines to virt-manager ==

If you want to convert a Windows (XP) physical machine you first may have to enable IDE in the registry. Start the machine and execute [[http://www.proxmox.com/cms_proxmox/cms/upload/misc/mergeide.reg|mergeide.reg]]. See [[http://support.microsoft.com/kb/314082/en-us|Microsoft KB Article 314082]].


=== using VMWare Converter ===

VMWare Converter is a free tool to migrate a physical machine to VMWare. So the first step is to migrate the physical machine to a VMware image. The second step is to follow the howto "How to convert VMWare Machines to virt-manager" (see above).


=== using linux tools ===

See the german book about qemu [[http://qemu-buch.de/de/index.php/QEMU-KVM-Buch/_Speichermedien/_Physical-to-Virtual|physical to virtual]]. There is a link to translate it in english. 


== Should ntp be used for time synchronisation? ==
Guests should not use ntp to synchronize the clock, so be sure to remove/disable ntpd

== Which driver should be used for Xorg? ==

=== Video ===
Linux guests with Xorg should be using the 'cirrus' video driver.  To use, adjust /etc/X11/xorg.conf to have: {{{
+#format wiki
#LANGUAGE it
<<BR>>
<<Indice(depth=2)>>
<<Informazioni(forum="http://forum.ubuntu-it.org/viewtopic.php?t=371617"; rilasci="25.10 25.04 24.04 22.04")>>

= 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 conflitti con altri hypervisor =

'''[[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.

== Prevenire conflitti con altri hypervisor ==

 0. Assicurarsi che tutte le macchine virtuali '''KVM''' siano spente. È consigliabile farlo tramite '''virt-manager''' oppure comando:{{{
virsh shutdown NOME_VM`
}}}
 0. Fermare il servizio '''libvirtd'''. Questo è il demone che gestisce le macchine virtuali '''KVM''' e che spesso mantiene i relativi moduli caricati.{{{
sudo systemctl stop libvirtd
}}}
 0. Rimuovere i moduli '''KVM''' del kernel. Dopo aver fermato '''libvirtd''' e assicurandosi che nessuna macchina virtuale '''KVM''' sia in esecuzione (anche avviata direttamente con '''qemu-system-x86_64'''), è possibile tentare di rimuovere i moduli per liberare le estensioni hardware di virtualizzazione.{{{
sudo modprobe -r kvm_intel kvm_amd kvm
}}}Una volta che i moduli KVM sono stati rimossi con successo è possibile avviare '''!VirtualBox''' o 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 oppure come ultima risorsa '''riavviare il sistema'''.
}}}

== Ripristinare KVM ==

 * Per ripristinare '''KVM''' dopo aver utilizzato un altro hypervisor è sufficiente avviare il servizio '''libvirtd''':{{{
sudo systemctl start libvirtd
}}}Questo ricaricherà automaticamente i moduli '''KVM''' necessari (ad esempio ''kvm'', ''kvm_intel'' o ''kvm_amd'') e riabiliterà la gestione delle VM '''KVM'''.

= Avvio VM con accesso al BIOS o GRUB =

Una macchina virtuale ha un BIOS/UEFI completo e può eseguire [[AmministrazioneSistema/Grub|GRUB]]. Talvolta la finestra della VM appare dopo che il BIOS o il menù di GRUB sono già scomparsi. Per assicurarsi di avere il tempo sufficiente per interagire con il BIOS o '''GRUB''' :
 0. spegnere la macchina virtuale.
 0. Eseguire '''virt-viewer''' con l'argomento `--wait`:{{{
virt-viewer --wait NOME_VM
}}}In questo modo '''virt-viewer''' attenderà l'avvio della macchina virtuale e la sua finestra apparirà non appena la VM inizia il boot.
 0. Avviare la macchina virtuale. Dovrebbe esserci il tempo sufficiente per poter interagire con il BIOS/UEFI, (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 è:
 0. selezionare nel menù [[AmministrazioneSistema/Grub|GRUB]] 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.

= Sincronizzazione ora =

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'utilizzo 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 utilizzare 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.
 0. Aprire con i [[AmministrazioneSistema/PrivilegiDiAmministrazione|privilegi di amministrazione]] e 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
-Linea 135:
+Linea 114:
-        Identifier      "Configured Video Device"
        Driver          "cirrus"
EndSection
}}} then be sure that your Screen section uses 'Configured Video Device' for its Device.

=== Mouse ===
Linux guests with Xorg should be using the 'vmmouse' driver (not available on Ubuntu Dapper).  To use, perform within the guest: {{{
aptitude install xserver-xorg-input-vmmouse
}}} then adjust /etc/X11/xorg.conf to have (the Identifier line should not change, and you should have only an Identifier line and Driver line for the mouse): {{{
Section "InputDevice"
        Identifier      "Configured Mouse"
        Driver          "vmmouse"
EndSection
}}}

== How to set up guest resolution in Xorg ? ==

Linux guests with Xorg need to adjust the resolution for Xorg in /etc/X11/xorg.conf.  Look for the Screen section, and make sure each of the 'Modes' lines has a reasonable resolution for your system (due to [[https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/193456|bug #193456]] the resolution in the guest's resolution needs to be smaller than the host). Eg: {{{
+Identifier "Card0"
Driver "vesa"
VendorName "QEMU/KVM"
BoardName "Standard VGA"
BusID "PCI:0:2:0"
EndSection
-Linea 154:
+Linea 122:
-        ...
        SubSection "Display"
                Depth           16
                Modes           "800x600" "640x480"
        EndSubSection
        SubSection "Display"
                Depth           24
                Modes           "800x600" "640x480"
        EndSubSection
EndSection
}}}

<<Anchor(systemadjustments)>>
== What system specific adjustments are recommended? ==

=== Windows (<Vista) ===
Windows (other than Vista) virtual machines should substitute in the .xml file: {{{
<features>
  <acpi/>
</features>
}}} with: {{{
<features/>
}}}

=== Windows Vista ===
Windows Vista virtual machines should add this to the xml file: {{{
+Identifier "Screen0"
Device "Card0"
Monitor "Monitor0"
SubSection "Display"
Viewport 0 0
Modes "1600x1200" "1024x768" "800x600"
EndSubSection
EndSection
}}}
 0. Per modificare la risoluzione è possibile cambiare i valori alla voce `Modes`.

== Configurazione driver video 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 ===

A ospite spento accedere alle impostazioni hardware della VM.
  0. Nella sezione ''''Video'''' selezionare il modello desiderato (es. '''QXL''' o '''virtio''').
  0. 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:{{{
<model type='vga' vram='9216' heads='1'/>
}}}
 * Per QXL (buone prestazioni, richiesto '''spice-vdagent''' nel guest):{{{
<model type='qxl' vram='65536' heads='1'/>
}}}
 * Per '''virtio-gpu''' (raccomandato per Linux guest moderni, per prestazioni ottimali e 3D con '''virglrenderer'''):{{{
<model type='virtio' heads='1' primary='yes'>
<acceleration accel3d='yes' accel2d='yes'/>
</model>
}}}

 I driver del mouse vmmouse sono presenti nella maggior parte delle distribuzioni Linux, ma per una migliore integrazione efunzionalità come il puntatore automatico, è raccomandato installare i '''qemu-guest-agent''' e usare '''virtio-input''' (spesso implicito con '''virtio-gpu''').

= Impostazione risoluzione guest con driver legacy =

Nell'eventualità che si stiano utilizzando 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 del parametro `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 `<features>` nel file `.xml` della VM.

 * Per Windows XP (e precedenti), se si hanno problemi con ACPI, provare a rimuovere `<acpi/>` o `<apic/>` nella sezione `<features>`.
 * Per Windows Vista, in alcuni casi l'aggiunta esplicita di ACPI può migliorare la stabilità (se non già presente):{{{
-Linea 182:
+Linea 195:
-  <features>
    <acpi/>
  </features>
+<features>
<acpi/>
</features>
-Linea 186:
+Linea 199:
-}}}

=== Debian Sarge ===
Debian Sarge (oldstable) may write /boot/grub/menu.lst incorrectly, resulting in the following on boot: {{{
pivot_root: no such file or directory
/sbin/init: 432: cannot open dev/console: no such file
Kernel panic: Attempted to kill init!
}}} The fix is at the grub menu, press 'e' and adjust {{{root=/dev/hdb1}}} to be {{{root=/dev/hda1}}}. After a successful boot, you will need to update /boot/grub/menu.lst to have: {{{
# kopt=root=/dev/hda1 ro
}}} and run: {{{
# update-grub
}}}

=== OpenBSD 4.1 (and others?) ===
OpenBSD 4.1 (and probably others) when using the rtl8139 network driver may realize poor network performance and see this message on the console:{{{
re0: watchdog timeout
}}} The fix is to use another NIC (e1000 appears to work well). See 'Changing the Network Card Model' above.

=== OpenBSD 4.5 and later ===
A change in the OpenBSD kernel causes it to hang on boot at "setting tty flags".  If this affects you, follow the instructions on http://scie.nti.st/2009/10/4/running-openbsd-4-5-in-kvm-on-ubuntu-linux-9-04

<<Include(KVM/Header)>>
+}}}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)
-Linea 209:
+Linea 212:
-----
CategoryHomepage CategoryInTraduzione
+CategoryVirtualizzazione