From Fedora Project Wiki
No edit summary
No edit summary
Line 60: Line 60:
*<code>virt-top</code>
*<code>virt-top</code>


== Introduzione alla virtualizzazione con Fedora ==
Per conoscere i dettagli di ciascun pacchetto consultare la sezione [[It_IT/Virtualization#Pacchetti_attinenti|I pacchetti relativi alla virualizzazione]].


Fedora supports multiple virtualization platforms. Different platforms require slightly different methods.  
== Avvio ==
 
Fedora supporta multiple piattaforme di virtualizzazione, ciascuna con le proprie metodologie seppur molto simili tra loro.  
When using KVM, to display all domains on the local system the command is <code>virsh -c qemu:///system list</code>.
Per esempio, per visualizzare tutti i domini sul sistema locale, con '''KVM''' si usa il comando
When using Xen, the same command is <code>virsh -c xen:///system list</code>.
virsh -c qemu:///system list
Be aware of this subtle variation.
mentre con '''Xen''' il comando diventa
 
virsh -c xen:///system list
To verify that virtualization is enabled on the system, run the following command, where <URI> is a valid URI that <code>libvirt</code> can recognize. For more details on URIs: see http://libvirt.org/uri.html.
Occhio a queste sottili differenze!
 
<pre>
$ su -c "virsh -c <URI> list"
Name                              ID Mem(MiB) VCPUs State  Time(s)
Domain-0                          0      610    1 r----- 12492.1
</pre>
 
The above output indicates that there is an active hypervisor. If virtualization is not enabled an error similar to the following appears:


Per controllare se la virtualizzazione sia abilitata o no, eseguire il seguente comando, dove <URI> è un URI valido riconosciuto da
<code>libvirt</code>:
$ su -c "virsh -c <URI> list"
Name                              ID Mem(MiB) VCPUs State  Time(s)
Domain-0                          0      610    1 r----- 12492.1
L'output indica che esiste un hypervisor attivo.<BR> Se la virtualizzazione non è abilitata, l'output sarà simile al seguente:
<pre>
<pre>
$ su -c "virsh -c <URI> list"
$ su -c "virsh -c <URI> list"
Line 84: Line 82:
error: no valid connection
error: no valid connection
</pre>
</pre>
In tal caso:
* Con Xen, assicurarsi che <code>xend</code> sia in esecuzione
* Con KVM, assicurarsi che <code>libvirtd</code>  sia in esecuzione
* Verificare che l'URI sia specificato correttamente


If the above error appears, make sure that:
Per maggiori dettagli su URI, consultare la sezione [http://docs.fedoraproject.org/virtualization-guide/f12/it-IT/html-single/#sect-Virtualization_Guide-Remote_management_of_virtualized_guests-Transport_modes 13.3. Modalità di trasporto] della documentazione e
* For Xen, ensure <code>xend</code> is running.
[http://libvirt.org/uri.html libvirt.org/uri].
* For KVM, ensure <code>libvirtd</code> is running.
* For either, ensure the URI is properly specified (see http://libvirt.org/uri.html for details).
 
 
{{Admon/note | Note that for the default setup, networking for the guest OS (DomU) is bridged. This means that DomU gets an IP address on the same network as Dom0. If a DHCP server provides addresses, it needs to be configured to give addresses to the guests. Another networking type can be selected by editing <code>/etc/xen/xend-config.sxp</code>}}
 
=== Creating a fedora guest ===
 
The installation of Fedora guests using anaconda is supported. The installation can be started on the command line via the <code>virt-install</code> program or in the GUI program <code>virt-manager</code>. You will be prompted for the type of virtualization (that is, KVM or Xen and para-virtualization or full virtualization) used during the guest creation process.


==== Creating a fedora guest with virt-install ====
{{Admon/note |
Notare che per impostazione predefinita, la rete per il S.O. guest (DomU) è connessa tramite bridg. Ciò significa che DomU ottiene un indirizzo IP sulla stessa rete di Dom0. Se è presente un server DHCP, occorre configurarlo per consentirgli di assegnare gli indirizzi ai guest. Si può selezionare un altro tipo di collegamento in rete modificando il file <code>/etc/xen/xend-config.sxp</code>}}


<code>virt-install</code> is a command line based tool for creating virtualized guests. To start the interactive install process, run the <code>virt-install</code> command:
== Creare un guest Fedora ==
E' possibile installare i guest Fedora usando anaconda. L'installazione può essere avviata da un terminale con il programma <code>virt-install</code> o con l'interfaccia grafica <code>virt-manager</code>. L'installazione chiederà il tipo di virtualizzazione da usare, KVM o Xen, virtualizzato o para-virtualizzato, durante il processo di creazione del guest.


=== Creare un guest Fedora con virt-install ===
<code>virt-install</code> è uno strumento a riga di comando per creare guest virtualizzati. Per avviare il processo interattivo d'installazione, eseguire il comando
<pre>
<pre>
su -c "/usr/sbin/virt-install"
su -c "/usr/sbin/virt-install"
</pre>
</pre>
 
Durante la fase di creazione verranno presentate le seguenti domande:
The following questions for the new guest will be presented.
# Qual'è il nome da assegnare alla virtual machine? Tale nome servirà ad identificare il S.O. guest. Il nome è usato con i comandi <code>virsh</code> e da  <code>virt-manager</code>(Virtual Machine Manager).
 
# Quanta memoria RAM deve essere allocata (in MB)? Questa è la quantità di RAM che sarà assegnata al guest in MegaByte (p.e. 256). Si raccomanda di allocare almeno 256MB per ogni guest.  
# What is the name of your virtual machine? This is the label that will identify the guest OS. This label is used with <code>virsh</code> commands and <code>virt-manager</code>(Virtual Machine Manager).
# Quale disco si desidera usare (percorso)? Il percorso locale ed il nome del file usati come immagine disco dal guest (p.e. /home/beppe/xenbox). Questo verrà esportato come un disco intero verso il guest.
# How much RAM should be allocated (in megabytes)? This is the amount of RAM to be allocated for the guest instance in megabytes (eg, 256). Note that installation with less than 256 megabytes is not recommended.
# Quanto grande si desidera il disco (in GB)? La dimensione del disco virtuale in GigaByte assegnata al guest (appare solo se il file specificato sopra non esiste già). Una dimensione ragionevole per una installazione ''tipica'' è di 4GB.
# What would you like to use as the disk (path)? The local path and file name of the file to serve as the disk image for the guest (eg, /home/joe/xenbox1). This will be exported as a full disk to your guest.
# Si desidera abilitare il supporto grafico (si o no)? Si chiede se si vuole usare l'installazione grafica.
# How large would you like the disk to be (in gigabytes)? The size of the virtual disk for the guest (only appears if the file specified above does not already exist). 4.0 gigabytes is a reasonable size for a "default" install
# Dove si trova l'installazione? Si chiede di specificare, nel formato usato da anaconda, il percorso ad una locazione di un albero di installazione di Fedora. Locazioni NFS, FTP, ed HTTP sono tutte supportate. Formati tipici sono i seguenti:  
# Would you like to enable graphics support (yes or no): Should the graphical installer be used?
# What is the install location? This is the path to a Fedora installation tree in the format used by anaconda. NFS, FTP, and HTTP locations are all supported. Examples include:
#* <code>nfs:my.nfs.server.com:/path/to/test2/tree/</code>
#* <code>nfs:my.nfs.server.com:/path/to/test2/tree/</code>
#* <code>http://my.http.server.com/path/to/tree/</code>
#* <code>http://my.http.server.com/path/to/tree/</code>
#* <code>ftp://my.ftp.server.com/path/to/tree</code>
#* <code>ftp://my.ftp.server.com/path/to/tree</code>
Il comando <code>virt-install</code> accetta anche ''opzioni'', per esempio per usare un file ''kickstart'' di nome kickstart-file-name.ks si esegue:
virt-install -x ks=kickstart-file-name.ks
oppure si inserisce l'opzione <code>--vnc</code> per aprire una finestra grafica durante l'installazione del guest.
Eseguire <code>virt-install --help</code> per maggiori dettagli.


These options can be passed as command line options, execute <code>virt-install --help</code> for details.
Se si è abilitato il supporto grafico, si aprirà una finestra VNC che avvierà l'installazione grafica. Altrimenti apparirà una installazione di tipo testuale. Procedere con l'installazione di Fedora.
 
<code>virt-install</code> can use kickstart files, for example
<code>virt-install -x ks=kickstart-file-name.ks</code>.
 
If graphics were enabled, a VNC window will open and present the graphical installer. If graphics were not enabled, a text installer will appear. Proceed with the fedora installation.
 
==== Creating a fedora guest with virt-manager ====
 
Start the GUI Virtual Machine Manager by selecting it from the "Applications-->System Tools" menu, or by running the following command:
<pre>
su -c "virt-manager"
</pre>
 
Enter the <code>root</code> password when prompted.
 
# Open a connection to a hypervisor by choosing File-->Open connection...
# Choose "qemu" for KVM, or "Xen" for Xen.
# Choose "local" or select a method to connect to a remote hypervisor
# After a connection is opened, click the new icon next to the hypervisor, or right click on the active hypervisor and select "New" (Note - the new icon is going to be improved to make it easier to see)
# A wizard will present the same questions as appear with the <code>virt-install</code> command-line utility (see descriptions above). The wizard assumes that a graphical installation is desired and does not prompt for this option.
# On the last page of the wizard there is a "Finish" button. When this is clicked, the guest OS is provisioned. After a few moments a VNC window should appear. Proceed with the installation as normal.
 
=== Remote management ===
 
The following remote management options are available:
* Create SSH keys for root, and use <code>ssh-agent</code> and <code>ssh-add</code> before launching <code>virt-manager</code>.
* Set up a local certificate authority and issue x509 certs to all servers and clients. For information on configuring this option, refer to http://libvirt.org/remote.html.
 
=== Guest system administration ===
 
When the installation of the guest operating system is complete, it can be managed using the GUI <code>virt-manager</code> program or on the command line using <code>virsh</code>.


==== Managing guests with virt-manager ====
Per maggiori informazioni consultare la sezione [http://docs.fedoraproject.org/virtualization-guide/f12/it-IT/html-single/#sect-Virtualization_Guide-Virtualized_guest_installation_overview-Creating_guests_with_virt_install  2.1. Creazione di un guest con virt-install]


Start the Virtual Machine Manager. Virtual Machine Manager is in the "Applications-->System Tools" menu, or execute:
=== Creare un guest Fedora con virt-manager ===
Avviare l'interfaccia grafica ''Virtual Machine Manager'' (selezionandola dal menu: Applicazioni --> Strumenti di Sistema), o da terminale con il comando:
<pre>
<pre>
su -c "virt-manager"
su -c "virt-manager"
</pre>
</pre>
Inserire, quando richiesto, la password di <code>root</code>. Superata l'autenticazione/autorizzazione, appare la finestra di dialogo di ''Virtual Machine Manager''.<BR>
Per sapere come usare al meglio tale strumento, fare riferimento alla sezione [http://docs.fedoraproject.org/virtualization-guide/f12/it-IT/html-single/#sect-Virtualization_Guide-Virtualized_guest_installation_overview-Creating_guests_with_virt_manager  2.2. Creazione di un guest con virt-manager] della documentazione. 


{1} If you are not root, you will be prompted to enter the root password. Choose<code>Run unprivileged</code> to operate in a read-only non-root mode.
=== Gestione remota ===
 
Per la gestione remota sono disponibili due possibilità:
* Choose "Local Xen Host" and click "Connect" in the "Open Connection" dialog window.
* Creare chiavi SSH per root, ed usare <code>ssh-agent</code> e <code>ssh-add</code> prima di avviare <code>virt-manager</code>.<BR> Per maggiori informazioni, consultare la sezione [http://docs.fedoraproject.org/virtualization-guide/f12/it-IT/html-single/#sect-Virtualization_Guide-Remote_management_of_virtualized_guests-Remote_management_with_SSH 13.1. Gestione remota con SSH] della documentazione.
* The list of virtual machines is displayed in the main window. The first machine is called "Domain 0"; this is the host computer.
* Impostare una authority di certificazione locale ed inviare certificazioni x509 a tutti i server e client.<BR> Per maggiori informazioni consultare la sezione [http://docs.fedoraproject.org/virtualization-guide/f12/it-IT/html-single/#sect-Virtualization_Guide-Remote_management_of_virtualized_guests-Remote_management_over_TLS_and_SSL 13.2. Gestione remota attraverso TLS e SSL] della documentazione, e [http://libvirt.org/remote.html libvirt.org-remote].
* If a machine is not listed, it is probably not running. To start up a machine select "File-->Restore a saved machine..." and select the file that serves as the guest's disk.
* The display lists the status, CPU and memory usage for each machine. Additional statistics can be selected under the "View" menu.
* Double click the name of a machine to open the virtual console.
* From the virtual console, select "View-->Details" to access the machine's properties and change its hardware configuration
* To access the serial console (if there is a problem with the graphical console) select "View-->Serial Console"
 
For further information about <code>virt-manager</code> consult the [http://virt-manager.et.redhat.com/ project website]
 
Bugs in the <code>virt-manager</code> tool should be reported in [http://bugzilla.redhat.com BugZilla]  against the 'virt-manager' component
 
==== Managing guests with virsh ====
 
The <code>virsh</code> command is a safe alternative to the <code>xm</code> command. <code>virsh</code> provides error checking and many other useful features over the <code>xm</code> command.
Guests can be managed on the command line with the <code>virsh</code> utility. The <code>virsh</code> utility is built around the libvirt management API and has a number of advantages over the traditional Xen <code>xm</code> tool:
 
* <code>virsh</code> has a stable set of commands whose syntax and semantics are preserved across updates to the underlying virtualization platform.
* <code>virsh</code> can be used as an unprivileged user for read-only operations (e.g. listing domains, listing domain statistics).
* <code>virsh</code> can manage domains running under Xen or KVM with no perceptible difference to the user
 
 
{{Admon/note | A valid URI must be passed to <code>virsh</code>. For details, see http://libvirt.org/uri.html}}
 
To start a virtual machine:
 
<pre>
su -c "virsh -c <URI> create <name of virtual machine>"
</pre>
 
To list the virtual machines currently running:
 
<pre>
su -c "virsh -c <URI> list"
</pre>
 
To gracefully power off a guest:
<pre>
su -c "virsh -c <URI> shutdown <virtual machine (name | id | uuid)>"
</pre>
 
To save a snapshot of the machine to a file:
<pre>
su -c "virsh -c <URI> save <virtual machine (name | id | uuid)> <filename>"
</pre>
 
To restore a previously saved snapshot:
<pre>
su -c "virsh -c <URI> restore <filename>"
</pre>
 
To export the configuration file of a virtual machine:
<pre>
su -c "virsh -c <URI> dumpxml <virtual machine (name | id | uuid)"
</pre>
 
For a complete list of commands available for use with <code>virsh</code>:
<pre>
su -c "virsh help"
</pre>
 
Or consult the manual page: <code>man 1 virsh</code>
 
Bugs in the <code>virsh</code> tool should be reported in [http://bugzilla.redhat.com BugZilla]  against the 'libvirt' component.
 
==== Managing guests with qemu-kvm ====
 
KVM virtual machines can also be managed in the command line using the 'qemu-kvm' command. See <code>man qemu</code> for more details.
 
== Troubleshooting virtualization ==
 
=== SELinux ===
 
The SELinux policy in Fedora has the necessary rules to allow the use of virtualization. The main caveat to be aware of is that any file backed disk images need to be in the directory {{filename|/var/lib/libvirt/images}}.  This applies both to regular disk images, and ISO images.  Block device backed disks are already labelled correctly to allow them to pass SELinux checks.
 
Beginning with [[Releases/11|Fedora 11]], virtual machines under SELinux are isolated from each other with [[Features/SVirt_Mandatory_Access_Control|sVirt]].
 
=== Log files ===
The graphical interface, <code>virt-manager</code>, used to  create and manage
virtual machines, logs to {{filename|$HOME/.virt-manager/virt-manager.log}}.
 
The <code>virt-install</code> tool, used to create virtual machines, logs to {{filename|$HOME/.virtinst/virt-install.log}}
 
Logging from <code>virt-manager</code> and <code>virt-install</code> may be increased by setting the environment variable <code>LIBVIRT_DEBUG=1</code>.
See http://libvirt.org/logging.html  
 
All QEMU command lines executed by <code>libvirt</code> are logged to {{filename|/var/log/libvirt/qemu/$DOMAIN.log}} where <code>$DOMAIN</code> is the name of the guest.
 
The <code>libvirtd</code> daemon is responsible for handling connections from
tools such as <code>virsh</code> and <code>virt-manager</code>.
The level and type of logging produced by <code>libvirtd</code>
may be modified in {{filename|/etc/libvirt/libvirtd.conf}}.
 
There are two log files stored on the host system to assist with debugging Xen related problems. The file {{filename|/var/log/xen/xend.log}} holds the same information reported with the '<code>xm log</code>' command.
 
The second file, {{filename|/var/log/xen/xend-debug.log}} usually contains much more detailed information.
 
When reporting errors, always include the output from both {{filename|/var/log/xen/xend.log}} and {{filename|/var/log/xen/xend-debug.log}} .
 
If starting a fully-virtualized domains (ie unmodified guest OS) there are also logs in {{filename|/var/log/xen/qemu-dm*.log}} which can contain useful information.
 
Xen hypervisor logs can be seen by running the '<code>xm dmesg</code>' command.
 
=== Serial console access for troubleshooting and management ===
Serial console access is useful for debugging kernel crashes and remote management can be very helpful. Accessing the serial consoles  of xen kernels or virtualized guests is slightly different to the normal procedure.
 
==== Host serial console access ====
 
If the Xen kernel itself has died and the hypervisor has generated an error, there is no way to record the error persistently on the local host.  Serial console lets you capture it on a remote host.
 
The Xen host must be setup for serial console output, and a remote host must exist to capture it.  For the console output, set the appropriate options in /etc/grub.conf:
 
<pre>
title Fedora
    root (hd0,1)
    kernel /vmlinuz-current.running.version com1=38400,8n1 sync_console
    module /vmlinuz-current.running.version ro root=LABEL=/ rhgb quiet console=ttyS0 console=tty pnpacpi=off
    module /initrd-current.running.version
</pre>
 
for a 38400-bps serial console on com1 (ie. /dev/ttyS0 on Linux.)  The "sync_console" works around a problem that can cause hangs with asynchronous hypervisor console output, and the "pnpacpi=off" works around a problem that breaks input on serial console.  "console=ttyS0 console=tty" means that kernel errors get logged both on the normal VGA console and on serial console.  Once that is done, install and set up <code>ttywatch</code> to capture the information on a remote host connected by a standard null-modem cable. For example, on the remote host:
 
<pre>
su -c "ttywatch --name myhost  --port /dev/ttyS0"
</pre>
 
Will log output from /dev/ttyS0 into a file /var/log/ttywatch/myhost.log
 
==== Para-virtualized guest serial console access ====
 
Para-virtualized guest OS will automatically have a serial console configured, and plumbed through to the Domain-0 OS. This can be accessed from the command line using
 
<pre>
su -c "virsh console &lt;domain name&gt;"
</pre>
 
Alternatively, the graphical <code>virt-manager</code> program can display the serial console. Simply display the 'console' or 'details' window for the guest and select 'View -> Serial console' from the menu bar.


==== Fully virtualized guest serial console access ====
== Amministrazione ==
Completata l'installazione del sisteam operativo guest, la sua gestione può avvalersi di due strumenti:
* <code>virt-manager</code>: interfaccia grafica
* <code>virsh</code>:  programma a linea di comando.


Fully-virtualized guest OS will automatically have a serial console configured, but the guest kernel will not be configured to use this out of the box. To enable the guest console in a Linux fully-virt guest, edit the /etc/grub.conf in the guest and add 'console=ttyS0 console=tty0'. This ensures that all kernel messages get sent to the serial console, and the regular graphical console. The serial console can then be access in same way as paravirt guests:
Per informazioni sull'uso di entrambi, consultare la documentazione relativa:
*[http://docs.fedoraproject.org/virtualization-guide/f12/it-IT/html-single/#chap-Virtualization_Guide-Managing_guests_with_virsh virsh]
*[http://docs.fedoraproject.org/virtualization-guide/f12/it-IT/html-single/#chap-Virtualization_Guide-Managing_guests_with_the_Virtual_Machine_Manager_virt_manager virt-manager]


<pre>
== Mailing List ==
su -c "virsh console &lt;domain name&gt;"
* Discussioni generali sulla virtualizzazione inclusi [http://www.linux-kvm.org/page/Main_Page KVM] and [http://www.nongnu.org/qemu/ QEMU]
</pre>
 
Alternatively, the graphical <code>virt-manager</code> program can display the serial console. Simply display the 'console' or 'details' window for the guest & select 'View -> Serial console' from the menu bar.
 
=== Accessing data on guest disk images ===
 
There are two tools which can help greatly in accessing data within a guest disk image: ''lomount'' and ''kpartx''.
 
{{Admon/caution | Remember never to do this while the guest is up and running, as it could corrupt the filesystem}}
 
{{admon/note|libguestfs|You can also try the experimental [http://et.redhat.com/~rjones/libguestfs/ libguestfs tools].}}
 
* '''lomount'''
 
<pre>
su -c "lomount -t ext3 -diskimage /xen/images/fc5-file.img -partition 1 /mnt/boot"
</pre>
 
lomount only works with small disk images and cannot deal with LVM volumes, so for more complex cases, kpartx (from the ''device-mapper-multipath'' RPM) is preferred:
 
* '''kpartx'''
 
<pre>
su -c "yum install device-mapper-multipath"
su -c "kpartx -av /dev/xen/guest1"
add map guest1p1 : 0 208782 linear /dev/xen/guest1 63
add map guest1p2 : 0 16563015 linear /dev/xen/guest1 208845
</pre>
 
Note that this only works for block devices, not for images installed on regular files.  To use file images, set up a loopback device for the file first:
 
<pre>
su -c "losetup -f"
/dev/loop0
su -c "losetup /dev/loop0 /xen/images/fc5-file.img"
su -c "kpartx -av /dev/loop0"
add map loop0p1 : 0 208782 linear /dev/loop0 63
add map loop0p2 : 0 12370050 linear /dev/loop0 208845
</pre>
 
In this case we have added an image formatted as a default Fedora install, so it has two partitions: one /boot, and one LVM volume containing everything else.  They are accessible under /dev/mapper:
 
<pre>
su -c "ls -l /dev/mapper/ | grep guest1"
brw-rw---- 1 root disk 253,  6 Jun  6 10:32 xen-guest1
brw-rw---- 1 root disk 253, 14 Jun  6 11:13 guest1p1
brw-rw---- 1 root disk 253, 15 Jun  6 11:13 guest1p2
su -c "mount /dev/mapper/guest1p1 /mnt/boot/"
</pre>
 
To access LVM volumes on the second partition, rescan LVM with <code>vgscan</code> and activate the volume group on that partition (named "VolGroup00" by default) with <code>vgchange -ay</code>:
 
<pre>
su -c "kpartx -a /dev/xen/guest1"
su -c "vgscan"
Reading all physical volumes.  This may take a while...
Found volume group "VolGroup00" using metadata type lvm2
su -c "vgchange -ay VolGroup00"
2 logical volume(s) in volume group "VolGroup00" now active
su -c "lvs"
LV        VG        Attr  LSize  Origin Snap%  Move Log Copy%
LogVol00  VolGroup00 -wi-a-  5.06G
LogVol01  VolGroup00 -wi-a- 800.00M
su -c "mount /dev/VolGroup00/LogVol00 /mnt/"
...
su -c "umount /mnt"
su -c "vgchange -an VolGroup00"
su -c "kpartx -d /dev/xen/guest1"
</pre>
 
{{Admon/caution | Note: '''Always''' deactivate the logical volumes with "vgchange -an", remove the partitions with "kpartx -d", and (if appropriate) delete the loop device with "losetup -d" after performing the above steps. The default volume group name for a Fedora install is always the same, it is important to avoid activating two volume group of the same name at the same time.  LVM will cope as best it can, but it is not possible to distinguish between these two groups on the command line. In addition, if the volume group is active on the host and the guest at the same time, it can cause filesystem corruption.}}
 
=== Getting help ===
If the Troubleshooting section above does not help you to solve your problem, check the
list of existing [[Virtualization bugs|virtualization bugs]], and search the archives of the mailing lists in the resources section. If you believe your problem is a previously undiscovered bug, please [[How to debug Virtualization problems|report it]] to Bugzilla.
 
==== Resources ====
* General virtualization discussion including [http://www.linux-kvm.org/page/Main_Page KVM] and [http://www.nongnu.org/qemu/ QEMU]
:  Fedora [http://www.redhat.com/mailman/listinfo/fedora-virt <code>fedora-virt</code>] mailing list
:  Fedora [http://www.redhat.com/mailman/listinfo/fedora-virt <code>fedora-virt</code>] mailing list


* [http://www.xen.org/ Xen] discussion
* Discussioni su [http://www.xen.org/ Xen]
: Fedora [http://www.redhat.com/mailman/listinfo/fedora-xen <code>fedora-xen</code>] mailing list
: Fedora [http://www.redhat.com/mailman/listinfo/fedora-xen <code>fedora-xen</code>] mailing list
: Xensource [http://lists.xensource.com/mailman/listinfo/xen-users <code>xen-users</code>] mailing list
: Xensource [http://lists.xensource.com/mailman/listinfo/xen-users <code>xen-users</code>] mailing list


* [http://www.virt-manager.org/ Virtual Machine Manager], <code>virt-inst</code> and related tools
* [http://www.virt-manager.org/ Virtual Machine Manager], <code>virt-inst</code> e strumenti relativi
: Red Hat [http://www.redhat.com/mailman/listinfo/et-mgmt-tools <code>et-mgmt-tools</code>] mailing list
: Red Hat [http://www.redhat.com/mailman/listinfo/et-mgmt-tools <code>et-mgmt-tools</code>] mailing list


* [http://www.libvirt.org Libvirt] discussion
* Discussioni su [http://www.libvirt.org Libvirt]
: Red Hat [http://www.redhat.com/mailman/listinfo/libvir-list <code>libvir-list</code>] mailing list
: Red Hat [http://www.redhat.com/mailman/listinfo/libvir-list <code>libvir-list</code>] mailing list


=== References ===
== Novità in Fedora 12/13 alla virtualizzazione ==
Per conoscere le novità apportate alla virtualizzazione in Fedora 12, come il miglioramento della gestione della memoria, fare riferimento<BR> alle [[It IT/Releases/12/FeatureList | note di rilascio di Fedora 12]] e alla ricca documentazione ufficiale sulla [http://docs.fedoraproject.org/virtualization-guide/f12/it-IT/html-single/ Virtualizzazione in Fedora 12].
 
Per conoscere le novità apportate alla virtualizzazione in Fedora 13, fare riferimento alle [[It IT/Releases/13/FeatureList | note di rilascio di Fedora 13]].
 
== Riferimenti ==
*


* http://www-128.ibm.com/developerworks/linux/library/l-linux-kvm/?ca=dgr-lnxw07LinuxKVM
Per scoprire altre teconologie di virtualizzazione disponibili per Linux in generale, e le relative caratteristiche e prestazioni,<BR> fare riferimento al sito [http://virt.kernelnewbies.org/TechComparison TechComparison].
* http://kerneltrap.org/node/8088


Previous Fedora Virtualization Guides:
Alcuni articoli generali:
* [http://www-128.ibm.com/developerworks/linux/library/l-linux-kvm/?ca=dgr-lnxw07LinuxKVM Discover the Linux Kernel Virtual Machine]
* [http://kerneltrap.org/node/8088 Interview: Avi Kivity]


[[Docs/Fedora7VirtQuickStart|  Fedora7VirtQuickStart]]


[[Docs/Fedora8VirtQuickStart|  Fedora8VirtQuickStart]]


[[Category:Italiano]]
[[Category:Italiano]]

Revision as of 17:40, 8 February 2010

La virtualizzazione su Fedora

Fedora consente la virtualizzazione con piattaforme KVM e Xen. Per scoprire altre teconologie di virtualizzazione disponibili per Linux in generale, e le relative caratteristiche e prestazioni, fare riferimento al sito TechComparison.

  • Xen supporta guest (o VM) para-virtualizzati come pure guest completamente virtualizzati con driver para-virtualizzati. La para-virtualizzazione è più veloce della virtualizzazione completa ma funziona solo su sistemi operativi Linux con le estensioni Xen nel kernel. Inoltre la piattaforma Xen completamente virtualizzata è più lenta della analoga KVM.
    Per informazioni generali, visitare il sito del progetto Xen; per conoscere lo stato corrente di Fedora a supporto di Xen consultare la nota di rilascio XenPvopsDom0.

Nota: Fedora usa la versione Xen 3.0.x, rilasciata nel Dicembre 2005, ed è incompatibile con guest creati usando le versioni Xen 2.0.x.

  • KVM propone una virtualizzazione completa e veloce, e necessita di hardware dedicato, ossia di un processore in grado di interpretare le istruzioni di virtualizzazione. KVM può funzionare su processori INTEL X_86 o AMD con estensioni alla virtualizzazione. Senza queste estensioni KVM usa il software di virtualizzazione QEMU.
    Per informazioni generali, visitare il sito del progetto KVM.

Preparare il sistema alla virtualizzazione

Questa sezione descrive come impostare Xen, KVM o entrambi sul proprio sistema. Dopo aver completato con successo le indicazioni suggerite, si potranno creare sistemi operativi guest. :-)

Requisiti Hardware

Spazio su disco rigido e memoria RAM

I requisiti minimi di memoria, di massa e volatile, per la virtualizzazione in Fedora sono:

  • Almeno 600MB di spazio su disco rigido per ciascun guest. Un sistema Fedora minimo in modalità text richiede 600MB di spazio. Guest desktop standard di Fedora almeno 3GB di spazio su disco rigido.
  • Almeno 256MB di RAM per ciascun guest + 256MB per il Sistema Operativo (S.O.) base. Si raccomandano circa 756MB, per ogni guest di un moderno S.O. Una buona regola è disporre tanto spazio quanto normalmente richiesto dal S.O. ed allocare tale quantità al guest virtualizzato.

Requisiti di processore per guest para-virtualizzati

Solo per piattaforma Xen, in quanto per il momento, KVM non supporta la para-virtualizzazione.
Processore x86_64 o INTEL Itanium o altro x86 con estensioni PAE. Molti portatili più vecchi (soprattutto quelli basati su Pentium Mobile / Centrino) non hanno supporto PAE. Per determinare se la CPU ha estensioni PAE, in un terminale, eseguire: 

$ grep pae /proc/cpuinfo
flags           : fpu tsc msr pae mce cx8 apic mtrr mca cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 
                  3dnow up ts

L'output indicato individua una CPU con estensioni PAE. Se il comando non ritorna nulla, allora la CPU non supporta la para-virtualizzazione.

Nota: Per versioni v di Fedora, con v < 10 è richiesto il pacchetto kernel-xen.
Per conoscere la situazione di Fedora corrente a supporto di Xen consultare la nota di rilascio XenPvopsDom0 relativa a Fedora 13.

Requisiti di processore per guest virtualizzati

La completa virtualizzazione con tecnologie Xen o KVM necessita di una CPU con estensioni alla virtualizzazione, cioè, le estensioni proprie di INTEL VT o AMD-V. Per verificare se la propria CPU INTEL abbia il supporto INTEL VT (ossia il flag vmx), come sopra: 

$ grep vmx /proc/cpuinfo
flags           : fpu tsc msr pae mce cx8 apic mtrr mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 
                  ss ht tm syscall nx lm  constant_tsc pni monitor ds_cpl vmx est tm2 cx16 xtpr lahf_lm

Su alcuni sistemi INTEL (solitamente portatili) le estensioni INTEL VT sono disabilitate nel BIOS. Entrare nel BIOS ed abilitare INTEL-VT o Vanderpool Technology, generalmente localizzato tra le opzioni delle CPU o nei menu del Chipset.

Per verificare se la propria CPU AMD ha supporto AMD-V (il flag svm): 

$ grep svm /proc/cpuinfo
flags           : fpu tsc msr pae mce cx8 apic mtrr mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall
                  nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy svm cr8_legacy

I processori VIA Nano usano l'insieme di istruzioni vmx.

Per ottenere la piena virtualizzazione anche su architetture prive di tale supporto, si può usare l'emulazione via software di QEMU. La virtualizzazione via software, tuttavia, risulterà molto più lenta di quella integrata in hardware tipica delle estensioni INTEL VT o AMD-V. QEMU inoltre può anche virtualizzare altre architetture di CPU, come ARM o PowerPC.

Installare i pacchetti necessari

Per installare i pacchetti relativi alla virtualizzazione, usando l'ambiente grafico di gestione dei pacchetti, selezionare nelle Collezioni di pacchetti, il gruppo Virtualizzazione, oppure usando un terminale 

su -c "yum groupinstall 'Virtualization'"

Il processo di installazione provedderà QEMU, KVM ed altri strumenti di virtualizzazione, in particolare:

  • qemu-kvm
  • python-virtinst
  • qemu
  • virt-manager
  • virt-viewer
  • e relative dipendenze.

Pacchetti opzionali sono:

  • gnome-applet-vm
  • virt-top

Per conoscere i dettagli di ciascun pacchetto consultare la sezione I pacchetti relativi alla virualizzazione.

Avvio

Fedora supporta multiple piattaforme di virtualizzazione, ciascuna con le proprie metodologie seppur molto simili tra loro. Per esempio, per visualizzare tutti i domini sul sistema locale, con KVM si usa il comando 

virsh -c qemu:///system list

mentre con Xen il comando diventa 

virsh -c xen:///system list

Occhio a queste sottili differenze!

Per controllare se la virtualizzazione sia abilitata o no, eseguire il seguente comando, dove <URI> è un URI valido riconosciuto da libvirt: 

$ su -c "virsh -c <URI> list"
Name                              ID Mem(MiB) VCPUs State  Time(s)
Domain-0                           0      610     1 r----- 12492.1

L'output indica che esiste un hypervisor attivo.
Se la virtualizzazione non è abilitata, l'output sarà simile al seguente: 

$ su -c "virsh -c <URI> list"
libvir: error : operation failed: xenProxyOpen
error: failed to connect to the hypervisor
error: no valid connection

In tal caso:

  • Con Xen, assicurarsi che xend sia in esecuzione
  • Con KVM, assicurarsi che libvirtd sia in esecuzione
  • Verificare che l'URI sia specificato correttamente

Per maggiori dettagli su URI, consultare la sezione 13.3. Modalità di trasporto della documentazione e libvirt.org/uri.

Notare che per impostazione predefinita, la rete per il S.O. guest (DomU) è connessa tramite bridg. Ciò significa che DomU ottiene un indirizzo IP sulla stessa rete di Dom0. Se è presente un server DHCP, occorre configurarlo per consentirgli di assegnare gli indirizzi ai guest. Si può selezionare un altro tipo di collegamento in rete modificando il file /etc/xen/xend-config.sxp

Creare un guest Fedora

E' possibile installare i guest Fedora usando anaconda. L'installazione può essere avviata da un terminale con il programma virt-install o con l'interfaccia grafica virt-manager. L'installazione chiederà il tipo di virtualizzazione da usare, KVM o Xen, virtualizzato o para-virtualizzato, durante il processo di creazione del guest.

Creare un guest Fedora con virt-install

virt-install è uno strumento a riga di comando per creare guest virtualizzati. Per avviare il processo interattivo d'installazione, eseguire il comando 

su -c "/usr/sbin/virt-install"

Durante la fase di creazione verranno presentate le seguenti domande:

  1. Qual'è il nome da assegnare alla virtual machine? Tale nome servirà ad identificare il S.O. guest. Il nome è usato con i comandi virsh e da virt-manager(Virtual Machine Manager).
  2. Quanta memoria RAM deve essere allocata (in MB)? Questa è la quantità di RAM che sarà assegnata al guest in MegaByte (p.e. 256). Si raccomanda di allocare almeno 256MB per ogni guest.
  3. Quale disco si desidera usare (percorso)? Il percorso locale ed il nome del file usati come immagine disco dal guest (p.e. /home/beppe/xenbox). Questo verrà esportato come un disco intero verso il guest.
  4. Quanto grande si desidera il disco (in GB)? La dimensione del disco virtuale in GigaByte assegnata al guest (appare solo se il file specificato sopra non esiste già). Una dimensione ragionevole per una installazione tipica è di 4GB.
  5. Si desidera abilitare il supporto grafico (si o no)? Si chiede se si vuole usare l'installazione grafica.
  6. Dove si trova l'installazione? Si chiede di specificare, nel formato usato da anaconda, il percorso ad una locazione di un albero di installazione di Fedora. Locazioni NFS, FTP, ed HTTP sono tutte supportate. Formati tipici sono i seguenti:

Il comando virt-install accetta anche opzioni, per esempio per usare un file kickstart di nome kickstart-file-name.ks si esegue: 

virt-install -x ks=kickstart-file-name.ks

oppure si inserisce l'opzione --vnc per aprire una finestra grafica durante l'installazione del guest. Eseguire virt-install --help per maggiori dettagli.

Se si è abilitato il supporto grafico, si aprirà una finestra VNC che avvierà l'installazione grafica. Altrimenti apparirà una installazione di tipo testuale. Procedere con l'installazione di Fedora.

Per maggiori informazioni consultare la sezione 2.1. Creazione di un guest con virt-install

Creare un guest Fedora con virt-manager

Avviare l'interfaccia grafica Virtual Machine Manager (selezionandola dal menu: Applicazioni --> Strumenti di Sistema), o da terminale con il comando: 

su -c "virt-manager"

Inserire, quando richiesto, la password di root. Superata l'autenticazione/autorizzazione, appare la finestra di dialogo di Virtual Machine Manager.
Per sapere come usare al meglio tale strumento, fare riferimento alla sezione 2.2. Creazione di un guest con virt-manager della documentazione.

Gestione remota

Per la gestione remota sono disponibili due possibilità:

Amministrazione

Completata l'installazione del sisteam operativo guest, la sua gestione può avvalersi di due strumenti:

  • virt-manager: interfaccia grafica
  • virsh: programma a linea di comando.

Per informazioni sull'uso di entrambi, consultare la documentazione relativa:

Mailing List

  • Discussioni generali sulla virtualizzazione inclusi KVM and QEMU
Fedora fedora-virt mailing list
  • Discussioni su Xen
Fedora fedora-xen mailing list
Xensource xen-users mailing list
Red Hat et-mgmt-tools mailing list
Red Hat libvir-list mailing list

Novità in Fedora 12/13 alla virtualizzazione

Per conoscere le novità apportate alla virtualizzazione in Fedora 12, come il miglioramento della gestione della memoria, fare riferimento
alle note di rilascio di Fedora 12 e alla ricca documentazione ufficiale sulla Virtualizzazione in Fedora 12.

Per conoscere le novità apportate alla virtualizzazione in Fedora 13, fare riferimento alle note di rilascio di Fedora 13.

Riferimenti

Per scoprire altre teconologie di virtualizzazione disponibili per Linux in generale, e le relative caratteristiche e prestazioni,
fare riferimento al sito TechComparison.

Alcuni articoli generali:

Retrieved from "https://fedoraproject.org/w/index.php?title=Getting_started_with_virtualization/it&oldid=151264"