Archive

Posts Tagged ‘xenserver’

Convertire .xva Xenserver Virtual Machine in una VM xen .img e avviare in KVM

kvmObiettivo. Convertire macchine  virtuali Windows XP e Windows 7 formato proprietario .xva,  Xenserver Citrix, in Virtual Machine xen .img ( plain xen ) e avviare la VM in KVM oppure in QEMU.  La conversione del formato .xva  in .img sarà realizzata in modo manuale è si basa su uno script di Carsten in Convert Citrix XenServer images to plain Xen – Tutorials / Howtos – Sysconfig’s Wiki. La procedura è stata usata su .xva generate da xenserver 5.6 e 6.0 con .xva anche da 120 GB e con 5 dischi.

Il formato .xva usato da XenServer è un po’ particolare per non dire stravagante. Per ottenere il formato nativo di xen è necessario decomprimere con tar i files .xva che sono archivi compressi.  La decompressione genera una directory Ref:x che conterrà blocchi da 1 MB.  I blocchi dovranno essere concatenati e gli spazi riempiti.

Decomprimere la VM .xva

Nella fase di decompressione verrà creata un dir del tipo Ref:x

tar xf VM-nome.xva   ## es. tar xf WindowsXP.xva 
...
tar: Ref:18/00008193: implausibly old time stamp 1970-01-01 01:00:00
tar: Ref:18/00008193.checksum: implausibly old time stamp 1970-01-01 01:00:00
... 

Prima di entrare nel directory generata e unire i blocchi. Creare lo script VMConvert.sh utilizzando il codice
di seguito

script VMConvert.sh

#!/bin/bash

dd if=/dev/zero of=blank bs=1024 count=1k
test -f $1.img && rm -f $1.img
touch $1.img

max=`ls ???????? | sort | tail -n1`

for i in `seq 0 $max`; do
        fn=`printf "%08d" $i`
        echo -n "$fn of $max"
        if [ -f "$fn" ]; then
                echo " - appending chunk"
                cat $fn >> $1.img
        else
                echo " - filling blank"
                cat blank >> $1.img
        fi
done

rm -f blank

echo "Done."

Rendiamo eseguibile lo script e passiamo nella dir Ref:x

chmod a+x VMConvert.sh 
cd Ref:x             ## es. cd Ref:18

Creare la VM xen standard

avviare l’operazione di concatenazione che genererà il file .img e la VM xen plain

sudo /percorso/VMconvert.sh  WindowsXP

L’operazione richiederà del tempo alla fine avremo l’immagine WindowsXP.img

Controllo dell’immagine xen .img

Il file .img potrà essere controllato effettuando il mount dell’immagine stessa. Per effettuare il mount è necessario determinare prima l’offset utilizzando  fdisk o parted. Con fdisk

/media/VM/QEMU/libvirt/images$ fdisk -l WindowsXP.img 

Disk WindowsXP.img: 25.8 GB, 25769803776 bytes
255 heads, 63 sectors/track, 3133 cylinders, total 50331648 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xc4a4c4a4

        Device Boot      Start         End      Blocks   Id  System
WindowsXP.img1   *          63    50315579    25157758+   7  HPFS/NTFS/exFAT

Start a 63 -> Sector size 512 -> offset= 63*512=32256

Determinato l’offset (32256) possiamo montare l’immagine con:

sudo mkdir /mnt/source
mount -o loop,offset=32256 WindowsXP.img /mnt/source

Avviare la VM Windows in KVM

Per avviare la VM WindowsXp che abbiamo convertito da .xva a .img  nell’infrastruttura di virtualizzazione, propria del kernel Linux, KVM spostiamo l’immagine nella dir con le nostre macchine virtuali per kvm.
Quindi Aprire virt-manager e utilizzare l’opzione import existing disk image.

virt -manager KVM import disk

virt -manager KVM import disk

Quindi [Forward]. Selezionare le desiderate e opportune opzioni e in poco tempo avremo la macchina Virutal Running anche in KVM.

virt-manager-WindowXP

Per un rapido test la macchina virtuale poteva essere avviata anche con

kvm -m 1024 -boot d WindowsXP.img

Risorse:

Xenserver Storage Repository (SR): aggiungere, collegare, rimuovere dischi

In Xenserver per gestire in modo completo gli storage repository (SR) di tipo local è necessario fare riferimento ai comandi da terminale (CLI)  piuttosto che utilizzare XenCenter.

Per visualizzare gli Storage Repository xe sr-list  (  per i suggerimenti e per i completamenti rispettivamente doppio [tab] e [tab])

# xe sr-list
uuid ( RO)                : 37239476-c08f-ad02-c776-77830c73d6c6
          name-label ( RW): Local storage
    name-description ( RW): 
                host ( RO): xs-602
                type ( RO): lvm
        content-type ( RO): user

uuid ( RO)                : 38faf3c9-f7ab-a8b6-4fb9-80a4745c2b05
          name-label ( RW): sr xenserver 5
    name-description ( RW): 
                host ( RO): xs-602
                type ( RO): lvm
        content-type ( RO): user

uuid ( RO)                : c425f5fb-1e60-685c-0a1c-6cc11a0087b7
          name-label ( RW): DVD drives
    name-description ( RW): Physical DVD drives
                host ( RO): xs-602
                type ( RO): udev
        content-type ( RO): iso
...
...

Aggiungere un Local Storage Repository (SR) a XenServer

Per poter aggiungere un Local Storage Repository visualizzare gli SR disponibili nel host con pvdisplay. Gli SR presenti potrebbero essere oltre a quello di default ( del server Xenserver ) uno o più Local Storage Repository aggiuntivi anche di altro XenServer o dischi collegati temporaneamente ( magari con un’installazione completa di XenServer).

# pvdisplay

  --- Physical volume ---
  PV Name               /dev/sda3
  VG Name               VG_XenStorage-37239476-c08f-ad02-c776-77830c73d6c6
  PV Size               290.09 GB / not usable 7.81 MB
  Allocatable           yes 
  PE Size (KByte)       4096
  Total PE              74260
  Free PE               17919
  Allocated PE          56341
  PV UUID               fOijAs-Dyb0-IUvH-5UzC-ivnj-Jx4u-c51TzT

  --- Physical volume ---
  PV Name               /dev/sdb3
  VG Name               VG_XenStorage-4f9d6505-0f10-5e08-9629-4a4813ec57a7
  PV Size               1.81 TB / not usable 8.06 MB
  Allocatable           yes 
  PE Size (KByte)       4096
  Total PE              474881
  Free PE               414464
  Allocated PE          60417
  PV UUID               JI2nT4-Aaj3-XIns-jpPy-YSJ6-isSV-9wkTsm

Per collegare il secondo disco da 1.8 TB è necessario:

  • far riconoscere lo Storage Repository (SR) a XenServer
  • creare il PBD physical block device per lo SR
  • infine collegare il PDB

Rendiamo lo Storage Repository riconoscibile con xe sr-introduce :

[root@xs61 ~]# xe sr-introduce uuid=4f9d6505-0f10-5e08-9629-4a4813ec57a7 type=lvm name-label="sr-l-T18" content-type=user
4f9d6505-0f10-5e08-9629-4a4813ec57a7

Lo SR apparirà ora anche in XenCenter è sarà marcato Detached.

Creare il PBD ( physical block device)  grazie al comando xe pdb-create.
Per poter utilizzare il comando è necessario disporre del host uuid  e del device name della partizione.

xe host-list
uuid ( RO)                : 6acdd0f6-cad4-4d46-b852-16c645e6c8b5
          name-label ( RW): xs-602
    name-description ( RW): Default install of XenServer

determinare il devicename di /dev/sdb3 con ls -l /dev/disk/by-id

[root@xs61 ~]# ls -l /dev/disk/by-id
total 0
lrwxrwxrwx 1 root root  9 Jan 13 13:57 scsi-SATA_WDC_WD20EARX-00_WD-WCAZAJ973153 -> ../../sdb
lrwxrwxrwx 1 root root 10 Jan 13 13:57 scsi-SATA_WDC_WD20EARX-00_WD-WCAZAJ973153-part1 -> ../../sdb1
lrwxrwxrwx 1 root root 10 Jan 13 13:57 scsi-SATA_WDC_WD20EARX-00_WD-WCAZAJ973153-part2 -> ../../sdb2
lrwxrwxrwx 1 root root 10 Jan 13 13:57 scsi-SATA_WDC_WD20EARX-00_WD-WCAZAJ973153-part3 -> ../../sdb3
lrwxrwxrwx 1 root root 10 Jan 13 13:57 scsi-SATA_WDC_WD20EARX-00_WD-WCAZAJ973153-part4 -> ../../sdb4
lrwxrwxrwx 1 root root  9 Jan 13 13:57 scsi-SATA_WDC_WD3201ABYS-_WD-WCARW3003070 -> ../../sda
lrwxrwxrwx 1 root root 10 Jan 13 13:57 scsi-SATA_WDC_WD3201ABYS-_WD-WCARW3003070-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10 Jan 13 13:57 scsi-SATA_WDC_WD3201ABYS-_WD-WCARW3003070-part2 -> ../../sda2
lrwxrwxrwx 1 root root 10 Jan 13 13:57 scsi-SATA_WDC_WD3201ABYS-_WD-WCARW3003070-part3 -> ../../sda3
lrwxrwxrwx 1 root root  9 Jan 13 13:57 usb-Generic_USB_CF_Reader_058F312D81B -> ../../sdd
lrwxrwxrwx 1 root root  9 Jan 13 13:57 usb-Generic_USB_MS_Reader_058F312D81B -> ../../sdf
...

Creare il PBD con   xe pbd-create

#  xe pbd-create host-uuid=6acdd0f6-cad4-4d46-b852-16c645e6c8b5 sr-uuid=4f9d6505-0f10-5e08-9629-4a4813ec57a7 device-config:device=/dev/disk/by-id/scsi-SATA_WDC_WD20EARX-00_WD-WCAZAJ973153-part3
7c37bb56-ee51-19b1-3df0-a5a4df9b385a

Quindi collegare con xe pbd-plug

# xe pbd-plug uuid=7c37bb56-ee51-19b1-3df0-a5a4df9b385a

Rimuovere uno  Storage Repository

Per rimuovere lo Storage Repository  aggiunto  SR-uuid= 4f9d6505-0f10-5e08-9629-4a4813ec57a7  dobbiamo ripetere al contrario le operazioni realizzate in precedenza.

  • scollegare il PBD physical block device dello Storage Repository con pbd-unplug
  • quindi rimuovere lo SR con sr-forget

Elencare i PBD con xe pbd-list

[root@localhost ~]# xe pbd-list
uuid ( RO)                  : 2513bd51-bce5-18a5-040f-64ccf6822aec
             host-uuid ( RO): 6acdd0f6-cad4-4d46-b852-16c645e6c8b5
               sr-uuid ( RO): 66c01d4b-911d-8cfd-d5a0-d78a5ad2f732
         device-config (MRO): location: /dev/xapi/block
    currently-attached ( RO): true

uuid ( RO)                  : 8bb8f425-59ff-e8b2-edf2-627708adcfb2
             host-uuid ( RO): 6acdd0f6-cad4-4d46-b852-16c645e6c8b5
               sr-uuid ( RO): c425f5fb-1e60-685c-0a1c-6cc11a0087b7
         device-config (MRO): location: /dev/xapi/cd
    currently-attached ( RO): true

uuid ( RO)                  : 7c37bb56-ee51-19b1-3df0-a5a4df9b385a
             host-uuid ( RO): 6acdd0f6-cad4-4d46-b852-16c645e6c8b5
               sr-uuid ( RO): 4f9d6505-0f10-5e08-9629-4a4813ec57a7
         device-config (MRO): device: /dev/disk/by-id/scsi-SATA_WDC_WD20EARX-00_WD-WCAZAJ973153-part3
    currently-attached ( RO): true

uuid ( RO)                  : 52449e07-4f89-bc68-1a8e-3887b74cb875
             host-uuid ( RO): 6acdd0f6-cad4-4d46-b852-16c645e6c8b5
               sr-uuid ( RO): 37239476-c08f-ad02-c776-77830c73d6c6
         device-config (MRO): device: /dev/disk/by-id/scsi-SATA_WDC_WD3201ABYS-_WD-WCARW3003070-part3
    currently-attached ( RO): true
...
..

Scollegare il pbd con

xe pbd-unplug uuid=7c37bb56-ee51-19b1-3df0-a5a4df9b385a

Rimuovere lo Storage Repository coin

xe sr-forget uuid=4f9d6505-0f10-5e08-9629-4a4813ec57a7

Creare un nuovo Storage Repository

E’ possibile aggiungere un disco a Xenserver e creare così un nuovo Storage Repository. Quando si aggiunge un hard disk xe sr-create è il comando da usare per la creazione di uno Storage Repository aggiuntivo. Il comando in questione è estremamente pericoloso poichè cancella i dati presenti nella partizione o disco.

La sintassi del comando :

xe sr-create name-label=<name> physical-size=<size> type=<type> content-type=<content_type> device-config:<config_name>=<value> [host-uuid=<Xen Cloud Platform host UUID>] [shared=<true | false>]

Per controllare i dischi accessibili da XenServer utilizzare fdisk -l


[root@localhost ~]# fdisk -l

Disk /dev/sda: 320.0 GB, 320072933376 bytes
...  boot drive  ...

Disk /dev/sdb: 2000.3 GB, 2000398934016 bytes
255 heads, 63 sectors/track, 243201 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
...

Per ottenere l’UUID del host fare rifeirmento a xe host-list

[root@localhost ~]# xe host-list
uuid ( RO)                : 6acdd0f6-cad4-4d46-b852-16c645e6c8b5
          name-label ( RW): xs-602
    name-description ( RW): Default install of XenServer
Qualora si aggiunga un nuovo disco a XenServer per utilizzarlo come un nuovo Storage Repository (SR ) .

Create il nuovo Storage Repository con un comando del tipo

xe sr-create name-label="xenloc2-2TBWD" type=lvm content-type=user device-config:device=/dev/sdb host-uuid=6acdd0f6-cad4-4d46-b852-16c645e6c8b5

Glossario

dom0  = dominio privilegiato.  E’  la Virtual Machine (VM) creata dall’Hypervisor di XenServe al boot. Il dominio privilegiato è  l’unico che ha accesso diretto all hardware e che si occupa di lanciare le altre VM .
domU = dominio non privilegiato .  Tutte le altre istanze di macchina virtuale (VM) in esecuzione diverse da dom0  sono dominioU:  viene creato un distinto dominio per ogni istanza.
Host:  la machine che esegue XenServer
Guest: una Virtual Machine  eseguita dentro XenServer.
VM : Virtual Machine, in XenServer è identificata da uno specifico uuid, ospitata in una Virtual Disk Image con un proprio vdi-uuid ed è connessa al dom0 grazie a un VBD con un suo vdb-uuid.
VDI:  Virtual Disk Image, un immagine o file che rappresenta un hard disk virtual.
VDB: Virtual Block Device, un modo per connettere una VDI a una virtual machine
UUID: Universally unique identifier. Una stringa di caratteri che XenServer, in questo caso, utilizza per idenficare in modo univoco un particolare oggetto ( http://en.wikipedia.org/wiki/UUID)

Altre risorse nle blog:


								

XenServer eliminare VDI in uso utilizzando l’interfaccia comandi ( CLI )

Scenario. L’operazione di copia su altro Storage Repository (SR) di una VM non è terminata correttamente. Il risultato è un disco (VDI), nome “Biblioteca”, collegato alla VM che non è possibile eliminare utilizzando XenCenter. Inoltre il comando xe vdi-destroy evidenzia che il VDI in questione risulta in uso:

# xe vdi-destroy uuid=c1e96819-089f-44b2-874b-b5facd9d4068 
This operation cannot be performed because this VDI is in use by some other operation
vdi: c1e96819-089f-44b2-874b-b5facd9d4068 (Biblioteca)
operation: destroy

In questo caso con tutta probabilità il disco VDI in oggetto risulterà ancora attaccato al dom0 (control domain) e pertanto in uso secondo la prospettiva di XenServer. Per rimuovere il disco “Biblioteca” bisogna ricorrere alla Command Line Interface (CLI). Di seguito le operazioni passo passo da compiere con l’indicazioni dell’utilizzo di [tab] e doppio [tab] per accelerare le operazioni (Per l’aiuto si può usare xe help, xe help -all e xe help “command” ).

La procedura indicata è stata testata su XenServer 6.1 tuttavia poichè utilizza comandi standard non dovrebbero esserci problemi anche con le versioni precedenti almeno fino alla 5.

Per visualizzare gli Storage Repository si può utilizzare il comando:

# xe sr-list
# xe sr-list
uuid ( RO)                : 37239476-c08f-ad02-c776-77830c73d6c6
          name-label ( RW): Local storage
    name-description ( RW): 
                host ( RO): xs-602
                type ( RO): lvm
        content-type ( RO): user

uuid ( RO)                : 4f9d6505-0f10-5e08-9629-4a4813ec57a7
          name-label ( RW): sr-l-T18
    name-description ( RW): 
                host ( RO): xs-602
                type ( RO): lvm
        content-type ( RO): user

uuid ( RO)                : 38faf3c9-f7ab-a8b6-4fb9-80a4745c2b05
          name-label ( RW): sr xenserver 5
    name-description ( RW): 
                host ( RO): xs-602
                type ( RO): lvm
        content-type ( RO): user
...
..

Per ricercare l’UUID  del VDI “Biblioteca” localizzato nello Storage Repository UUID=4f9d6505-0f10-5e08-9629-4a4813ec57a7.

# xe vdi-list

doppio tab per evidenziare gli argomenti disponibili

# xe vdi-list
allow-caching=                missing=                      snapshot-time=
allowed-operations=           name-description=             sr-name-label=
allowed-operations:contains=  name-label=                   sr-uuid=
crashdump-uuids=              on-boot=                      storage-lock=
crashdump-uuids:contains=     other-config=                 tags=
current-operations=           params=                       tags:contains=
current-operations:contains=  parent=                       type=
database:                     physical-utilisation=         uuid=
is-a-snapshot=                read-only=                    vbd-uuids=
location=                     sharable=                     vbd-uuids:contains=
managed=                      sm-config=                    virtual-size=
metadata-latest=              snapshot-of=                  xenstore-data=
metadata-of-pool=             snapshots=

Poichè sono presenti più local storage repository (SR) usiamo anche il parametro sr-uuid così da limitare i VDI visualizzati.
Tab per completare doppio tab per avere l’elenco degli SR disponibili

# xe vdi-list sr-uuid=
[root@localhost ~]# xe vdi-list sr-uuid=
37239476-c08f-ad02-c776-77830c73d6c6   66c01d4b-911d-8cfd-d5a0-d78a5ad2f732 
38faf3c9-f7ab-a8b6-4fb9-80a4745c2b05   c425f5fb-1e60-685c-0a1c-6cc11a0087b7 
4f9d6505-0f10-5e08-9629-4a4813ec57a7   f9dc6463-379d-844e-6b2f-1f313f7b96eb

un solo tab per completare su sr-uuid=4f9

[root@localhost ~]# xe vdi-list sr-uuid=4f9d6505-0f10-5e08-9629-4a4813ec57a7 
uuid ( RO)                : 2b49dbf2-4676-4de9-9e3d-f12797b6076a
          name-label ( RW): Lubu1110
    name-description ( RW): Lubuntu1110 Copy
             sr-uuid ( RO): 4f9d6505-0f10-5e08-9629-4a4813ec57a7
        virtual-size ( RO): 8589934592
            sharable ( RO): false
           read-only ( RO): false

uuid ( RO)                : c1e96819-089f-44b2-874b-b5facd9d4068
          name-label ( RW): Biblioteca
    name-description ( RW): 100% XP ori
             sr-uuid ( RO): 4f9d6505-0f10-5e08-9629-4a4813ec57a7
        virtual-size ( RO): 64424509440
            sharable ( RO): false
           read-only ( RO): false

Adesso dobbiamo ricercare il VBD (virtual block device) del nostro VDI “Biblioteca” che dovrebbe evidenziare la connessione al dom0.
tab su xe vbd-list uuid=c1e  per completare l’uuid oppure taglia incolla

xe vbd-list vdi-uuid=c1e96819-089f-44b2-874b-b5facd9d4068

Se il VDI in oggetto fosse una macchina virtuale potrebbero essere presenti due VBD uno per la VM e uno per il dom0. Nel nostro caso il VDI “Biblioteca” è uno disco di storage e quindi ci aspettiamo una solo VBD verso dom0.

[root@localhost ~]# xe vbd-list vdi-uuid=c1e96819-089f-44b2-874b-b5facd9d4068 
uuid ( RO)             : 8d5590c6-759d-5bf3-ce62-104be70b0545
          vm-uuid ( RO): 6b74bc18-469c-46b1-b2e8-21caee26475f
    vm-name-label ( RO): Control domain on host: xs-602
         vdi-uuid ( RO): c1e96819-089f-44b2-874b-b5facd9d4068
            empty ( RO): false
           device ( RO): sm/backend/4f9d6505-0f10-5e08-9629-4a4813ec57a7/c1e96819-089f-44b2-874b-b5facd9d4068

Il risultato conferma le attese. Per poter cancellare il VDI dobbiamo pertanto scollegare ( unplug ) il disco dal dom0 con xe vbd-unplug.

xe vbd-unplug uuid=8d5590c6-759d-5bf3-ce62-104be70b0545

Quindi eliminare il block device con

xe vbd-destroy uuid=8d5590c6-759d-5bf3-ce62-104be70b0545

Scollegato il vdi dal dom0 adesso sarà possibile rimuovere il disco utilizzando XenCenter oppure con il comando xe vdi-destroy.
possiamo usare i tab per il completamenti vari

xe vdi-destroy uuid=c1e96819-089f-44b2-874b-b5facd9d4068

Glossario

dom0  = dominio privilegiato.  E’  la Virtual Machine (VM) creata dall’Hypervisor di XenServe al boot. Il dominio privilegiato è  l’unico che ha accesso diretto all hardware e che si occupa di lanciare le altre VM .
domU = dominio non privilegiato .  Tutte le altre istanze di macchina virtuale (VM) in esecuzione diverse da dom0  sono dominioU:  viene creato un distinto dominio per ogni istanza.
Host:  la machine che esegure XenServer
Guest: una Virtual Machine  eeeguita dentro XenServer.
VM : Virtual Machine, in XenServer è identificata da uno specifico uuid è ospitata in una Virtual Disk Image con un proprio vdi-uuid ed è connessa al dom0 grazie a un VBD con un suo vdb-uuid.
VDI:  Virtual Disk Image, un immagine o file che rappresenta un hard disk virtual.
VDB: Virtual Block Device, un modo per connettere una VDI a una virtual machine
UUID: Universally unique identifier. Una stringa di caratteri che XenServer, in this case, per idenficare in modo univoco un particolare oggetto. You can read more at http://en.wikipedia.org/wiki/UUID

Altre risorse nle blog:


								

Xenserver detach and re-attach a local storage repository separate disk

Googling I found that would be useful to add instructions on how to detach and re-attach a local storage ( separate disk ) to XenServer.  It is necessary to use command line interface (CLI).

We can see Storage Repository using xe sr-list:

# xe sr-list
uuid ( RO)                : 37239476-c08f-ad02-c776-77830c73d6c6
          name-label ( RW): Local storage
    name-description ( RW): 
                host ( RO): xs-602
                type ( RO): lvm
        content-type ( RO): user

uuid ( RO)                : 38faf3c9-f7ab-a8b6-4fb9-80a4745c2b05
          name-label ( RW): sr xenserver 5
    name-description ( RW): 
                host ( RO): xs-602
                type ( RO): lvm
        content-type ( RO): user

uuid ( RO)                : c425f5fb-1e60-685c-0a1c-6cc11a0087b7
          name-label ( RW): DVD drives
    name-description ( RW): Physical DVD drives
                host ( RO): xs-602
                type ( RO): udev
        content-type ( RO): iso
...
...

Add a Local Storage Repository ( SR )

To add a Local Storage Repository check the SR available in the host using pv display. We can see the default XenServer Local SR and if there are others disks attached others SR. Disks  maybe temporary attached and with full XenServer installation,too.

# pvdisplay

  --- Physical volume ---
  PV Name               /dev/sda3
  VG Name               VG_XenStorage-37239476-c08f-ad02-c776-77830c73d6c6
  PV Size               290.09 GB / not usable 7.81 MB
  Allocatable           yes 
  PE Size (KByte)       4096
  Total PE              74260
  Free PE               17919
  Allocated PE          56341
  PV UUID               fOijAs-Dyb0-IUvH-5UzC-ivnj-Jx4u-c51TzT

  --- Physical volume ---
  PV Name               /dev/sdb3
  VG Name               VG_XenStorage-4f9d6505-0f10-5e08-9629-4a4813ec57a7
  PV Size               1.81 TB / not usable 8.06 MB
  Allocatable           yes 
  PE Size (KByte)       4096
  Total PE              474881
  Free PE               414464
  Allocated PE          60417
  PV UUID               JI2nT4-Aaj3-XIns-jpPy-YSJ6-isSV-9wkTsm

We can see two LVM volumes. The first, in sda disk, is the main XenServer  local SR, the second is 1.8 TB LVM volume in sdb disk. To attach SR is necessary :

  • recognize the Storage Repository in XenServer 
  • create the SR physical block device (PBD)
  • then plug the PBD to XenServer

Let the Storage Repository recognizable using xe sr-introduce

[root@xs61 ~]# xe sr-introduce uuid=4f9d6505-0f10-5e08-9629-4a4813ec57a7 type=lvm name-label="sr-l-T18" content-type=user
4f9d6505-0f10-5e08-9629-4a4813ec57a7

Now we can see  SR  in XenCenter and it will be marked as Detached.

We have to create the  PBD ( physical block device)  using xe pdb-create command. To use the command, you need the host uuid  and  device name of the partition.

xe host-list
uuid ( RO)                : 6acdd0f6-cad4-4d46-b852-16c645e6c8b5
          name-label ( RW): xs-602
    name-description ( RW): Default install of XenServer

To know the  /dev/sdb3 devicename we can use  ls -l /dev/disk/by-id

[root@xs61 ~]# ls -l /dev/disk/by-id
total 0
lrwxrwxrwx 1 root root  9 Jan 13 13:57 scsi-SATA_WDC_WD20EARX-00_WD-WCAZAJ973153 -> ../../sdb
lrwxrwxrwx 1 root root 10 Jan 13 13:57 scsi-SATA_WDC_WD20EARX-00_WD-WCAZAJ973153-part1 -> ../../sdb1
lrwxrwxrwx 1 root root 10 Jan 13 13:57 scsi-SATA_WDC_WD20EARX-00_WD-WCAZAJ973153-part2 -> ../../sdb2
lrwxrwxrwx 1 root root 10 Jan 13 13:57 scsi-SATA_WDC_WD20EARX-00_WD-WCAZAJ973153-part3 -> ../../sdb3
lrwxrwxrwx 1 root root 10 Jan 13 13:57 scsi-SATA_WDC_WD20EARX-00_WD-WCAZAJ973153-part4 -> ../../sdb4
lrwxrwxrwx 1 root root  9 Jan 13 13:57 scsi-SATA_WDC_WD3201ABYS-_WD-WCARW3003070 -> ../../sda
lrwxrwxrwx 1 root root 10 Jan 13 13:57 scsi-SATA_WDC_WD3201ABYS-_WD-WCARW3003070-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10 Jan 13 13:57 scsi-SATA_WDC_WD3201ABYS-_WD-WCARW3003070-part2 -> ../../sda2
lrwxrwxrwx 1 root root 10 Jan 13 13:57 scsi-SATA_WDC_WD3201ABYS-_WD-WCARW3003070-part3 -> ../../sda3
lrwxrwxrwx 1 root root  9 Jan 13 13:57 usb-Generic_USB_CF_Reader_058F312D81B -> ../../sdd
lrwxrwxrwx 1 root root  9 Jan 13 13:57 usb-Generic_USB_MS_Reader_058F312D81B -> ../../sdf
...

The PBD  is created using  xe pbd-create

#  xe pbd-create host-uuid=6acdd0f6-cad4-4d46-b852-16c645e6c8b5 sr-uuid=4f9d6505-0f10-5e08-9629-4a4813ec57a7 device-config:device=/dev/disk/by-id/scsi-SATA_WDC_WD20EARX-00_WD-WCAZAJ973153-part3
7c37bb56-ee51-19b1-3df0-a5a4df9b385a

Then we can connect with  xe pbd-plug

# xe pbd-plug uuid=7c37bb56-ee51-19b1-3df0-a5a4df9b385a

Remove a  Storage Repository

To remove the Storage Repository added SR-uuid= 4f9d6505-0f10-5e08-9629-4a4813ec57a7  we have to reverse  the actions previosuly made.

  • unplung the Storage Repository PBD ( physical block device ) using pbd-unplug
  • then remove SR with  sr-forget

We can list PBD using xe pbd-list

[root@localhost ~]# xe pbd-list
uuid ( RO)                  : 2513bd51-bce5-18a5-040f-64ccf6822aec
             host-uuid ( RO): 6acdd0f6-cad4-4d46-b852-16c645e6c8b5
               sr-uuid ( RO): 66c01d4b-911d-8cfd-d5a0-d78a5ad2f732
         device-config (MRO): location: /dev/xapi/block
    currently-attached ( RO): true

uuid ( RO)                  : 8bb8f425-59ff-e8b2-edf2-627708adcfb2
             host-uuid ( RO): 6acdd0f6-cad4-4d46-b852-16c645e6c8b5
               sr-uuid ( RO): c425f5fb-1e60-685c-0a1c-6cc11a0087b7
         device-config (MRO): location: /dev/xapi/cd
    currently-attached ( RO): true

uuid ( RO)                  : 7c37bb56-ee51-19b1-3df0-a5a4df9b385a
             host-uuid ( RO): 6acdd0f6-cad4-4d46-b852-16c645e6c8b5
               sr-uuid ( RO): 4f9d6505-0f10-5e08-9629-4a4813ec57a7
         device-config (MRO): device: /dev/disk/by-id/scsi-SATA_WDC_WD20EARX-00_WD-WCAZAJ973153-part3
    currently-attached ( RO): true

uuid ( RO)                  : 52449e07-4f89-bc68-1a8e-3887b74cb875
             host-uuid ( RO): 6acdd0f6-cad4-4d46-b852-16c645e6c8b5
               sr-uuid ( RO): 37239476-c08f-ad02-c776-77830c73d6c6
         device-config (MRO): device: /dev/disk/by-id/scsi-SATA_WDC_WD3201ABYS-_WD-WCARW3003070-part3
    currently-attached ( RO): true
...
..

Unplug  PBD with

xe pbd-unplug uuid=7c37bb56-ee51-19b1-3df0-a5a4df9b385a

Remove Storage Repository using

xe sr-forget uuid=4f9d6505-0f10-5e08-9629-4a4813ec57a7

Create  a new Storage Repository

To create a new Storage Repository when you add a new disk you have to use the command xe sr-create. The command in question is an extremely dangerous command because it deletes the data on the partition or disk ( So beware).

The command syntax is:

xe sr-create name-label=<name> physical-size=<size> type=<type> content-type=<content_type> device-config:<config_name>=<value> [host-uuid=<Xen Cloud Platform host UUID>] [shared=<true | false>]

To check the disks accessible from XenServer use fdisk -l


[root@localhost ~]# fdisk -l

Disk /dev/sda: 320.0 GB, 320072933376 bytes
...  boot drive  ...

Disk /dev/sdb: 2000.3 GB, 2000398934016 bytes
255 heads, 63 sectors/track, 243201 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
...

To get the UUID of the host refer to xe host-list

[root@localhost ~]# xe host-list
uuid ( RO)                : 6acdd0f6-cad4-4d46-b852-16c645e6c8b5
          name-label ( RW): xs-602
    name-description ( RW): Default install of XenServer
Qualora si aggiunga un nuovo disco a XenServer per utilizzarlo come un nuovo Storage Repository (SR ) .

Create a new Storage Repository using a command like

xe sr-create name-label="xenloc2-2TBWD" type=lvm content-type=user device-config:device=/dev/sdb host-uuid=6acdd0f6-cad4-4d46-b852-16c645e6c8b5

Glossario

dom0  =  privileged domain. It ‘s the Virtual Machine (VM) created by the hypervisor XenServe at boot. The privileged domain is the one that has direct access to the hardware and is responsible for launching other VM.
domU = unprivileged domU domain. All other instances of the virtual machine (VM) running other than dom0 are dominioU: it’is created a separate domain for each instance.
Host:  the machine running XenServer
Guest: a Virtual Machine  running in XenServer.
VM : Virtual Machine in XenServer is identified by a specific uuid and hosted on a Virtual Disk Image with its own vdi-uuid and is connected to dom0 via a VBD with his vdb-uuid.
VDI:   Virtual Disk Image, the image or file is a virtual hard disk.
VDB: Virtual Block Device, a way to connect a VDI to a virtual machine
UUID: Universally unique identifier. A string of characters that XenServer, in this case, use to uniquely identify an object. You can read more at http://en.wikipedia.org/wiki/UUID

Altre risorse nle blog:


								

Montare la partizione LVM di una VM guest in XenServer 5.6 SP2

settembre 16, 2012 Lascia un commento

Montare la partizione di una VM  ospite così da poter interagire con il file system recuperando eventualmente alcuni file. Il metodo sfrutta il fatto che Dom0 ( host machine ) si comporta come una VM quindi è possibile per la disk image virtuale (VDI) di una VM creare una nuovo VDB e quindi connettere la VDI all’host. LO stesso metodo è usato quando una VDI viene connessa a qualsiasi altro guest.

Glossario

dom0  = dominio privilegiato.  E’  la Virtual Machine (VM) creata dall’Hypervisor di XenServe al boot. Il dominio privilegiato è  l’unico che ha accesso diretto all hardware e che si occupa di lanciare le altre VM .
domU = dominio non privilegiato .  Tutte le altre istanze di macchina virtuale (VM) in esecuzione diverse da dom0  sono dominioU:  viene creato un distinto dominio per ogni istanza.
Host:  la machine che esegure XenServer
Guest: una Virtual Machine  eeeguita dentro XenServer.
VM : Virtual Machine, in XenServer è identificata da uno specifico uuid è ospitata in una Virtual Disk Image con un proprio vdi-uuid ed è connessa al dom0 grazie a un VBD con un suo vdb-uuid.
VDI:  Virtual Disk Image, un immagine o file che rappresenta un hard disk virtual.
VDB: Virtual Block Device, un modo per connettere una VDI a una virtual machine
UUID: Universally unique identifier. Una stringa di caratteri che XenServer, in this case, per idenficare in modo univoco un particolare oggetto. You can read more at http://en.wikipedia.org/wiki/UUID

Montaggio della partizione LVM di una VM

Dalla console di XenServer host (dom0) ricerchiamo l’UUID della stessa Dom0 VM:

xe vm-list | grep -B 1 -e Control
[root@localhost ~]#  xe vm-list | grep -B 1 -e Control
uuid ( RO)           : bddad094-84a3-49ef-89c9-8f26fe88200d
     name-label ( RW): Control domain on host: xenserver-jlvuukyx

Dalla console di XenServer host (dom0) ricerchiamo l’UUID del VDI della VM alla quale dobbiamo accedere. Esistono più metodi questo consente di ottenere il VBD e il VDI della specifica VM

xe vm-list name-label=<vm-name>
o
 xe vm-disk-list uuid=<vm-uuid>
[root@localhost ~]# xe vbd-list vm-name-label="Ubuntu Precise Pangolin 12.04 (64-bit)] (1)"
uuid ( RO)             : fc7be39f-661a-4efb-52ba-dba755c944c0   (VBD)
          vm-uuid ( RO): f09353ee-f7bd-3825-5fb2-6e97cfb7356a    
    vm-name-label ( RO): Ubuntu Precise Pangolin 12.04 (64-bit)] (1)
         vdi-uuid ( RO): ecc801e0-f24c-4b31-a391-2e10bc9baeeb
            empty ( RO): false
           device ( RO): xvda

uuid ( RO)             : 6dbe9231-c24a-f736-7b8e-0446509184e4    
          vm-uuid ( RO): f09353ee-f7bd-3825-5fb2-6e97cfb7356a
    vm-name-label ( RO): Ubuntu Precise Pangolin 12.04 (64-bit)] (1)
         vdi-uuid ( RO): 
            empty ( RO): true
           device ( RO): xvdd

o

[root@localhost ~]#  xe vm-disk-list uuid=f09353ee-f7bd-3825-5fb2-6e97cfb7356a
Disk 0 VBD:
uuid ( RO)             : fc7be39f-661a-4efb-52ba-dba755c944c0
    vm-name-label ( RO): Ubuntu Precise Pangolin 12.04 (64-bit)] (1)
       userdevice ( RW): 0

Disk 0 VDI:
uuid ( RO)             : ecc801e0-f24c-4b31-a391-2e10bc9baeeb
       name-label ( RW): Ubuntu Precise Pangolin 12.04 (64-bit)] (1) 0
    sr-name-label ( RO): Local storage
     virtual-size ( RO): 8589934592

Creiamo un nuovo VBD per il virtual disk (VDI) della VM guest in oggetto. Il comando ritornera l’uuid del VBD creato.

xe vbd-create device=0 vm-uuid=<uuid-dom0>  vdi-uuid=<uuid-vm-disk>
[root@localhost]# xe vbd-create vm-uuid=bddad094-84a3-49ef-89c9-8f26fe88200d vdi-uuid=ecc801e0-f24c-4b31-a391-2e10bc9baeeb device=autodetect 
4e55fd78-d367-ccc0-dfc8-f06557080217

attacchiamo a dom0 il VDI grazie al nuovo VBD

xe vbd-plug uuid=uuid-del-nuovo-vbd
xe vbd-plug uuid=4e55fd78-d367-ccc0-dfc8-f06557080217

A questo punto dovrebbe già essere possibile il mount delle partizioni del VDI.
( In alternativa continuare con il device mapping vedi sotto )
Con fdisk -l sarà possibile visualizzare le partizioni del device /dev/xvdc
che potranno essere montate in modo classico con mount

[root@localhost ~]# fdisk -l
....
....
Partition table entries are not in disk order

Disk /dev/xvdc: 8589 MB, 8589934592 bytes
255 heads, 63 sectors/track, 1044 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

    Device Boot      Start         End      Blocks   Id  System
/dev/xvdc1   *           1          32      248832   83  Linux
Partition 1 does not end on cylinder boundary.
/dev/xvdc2              32        1045     8136705    5  Extended
/dev/xvdc5             980        1045      522240   82  Linux swap / Solaris
/dev/xvdc6              32         980     7614464   83  Linux

Partition table entries are not in disk order

con blkid

....
/dev/xvdc1: UUID="35541399-3d95-4062-a01f-4a4e422a923a" TYPE="ext4" 
/dev/xvdc5: TYPE="swap" UUID="a0e6a65f-7bb4-4fc8-9552-ced71d1605f3" 
/dev/xvdc6: UUID="dd26435b-c609-45ae-b474-bffc88350a14" TYPE="ext4"

Montaggio ad esempio

mkdir /tmp/c-boot
mkdir /mnt/c-root
mount /dev/xvdc1  /mnt/c-boot
mount /dev/xvdc6  /mnt/c-root

Per analizzare la situazione delle partizioni in gioco utilizzare i comandi

fdisk -l 
df -a
blkid

Ripristino condizione iniziale

Terminata l’azione sul file system bisogna ripristino delle condizioni iniziali diversamente la VM non può essere avviata.

Smontare i volumi logici con

umount /tmp/c-boot
umount /tmp/c-root

controllare l’esistenza di ulteriori punti di mount con

  df -a

disconnettere il VBD

xe vbd-unplug uuid=VBD-uuid
[root@localhost /]# xe vbd-unplug uuid=4e55fd78-d367-ccc0-dfc8-f06557080217

Eliminare il VBD

xe vbd-destroy uuid=VBD-uuid
[root@localhost /]# xe vbd-destroy uuid=4e55fd78-d367-ccc0-dfc8-f06557080217

Aternativa: continuare con il device mapping

Per confermare che il device creato (xvdc)

[root@localhost tmp]# xe vbd-list uuid=4e55fd78-d367-ccc0-dfc8-f06557080217 params=device --minimal
xvdc

Quindi utilizziamo kpartx per effettuare il mounting delle partizioni del disco virtuale (VDI)

kpartx -a /dev/xvda
root@localhost /]# kpartx /dev/xvdc 
xvdc1 : 0 497664 /dev/xvdc 2048
xvdc5 : 0 1044480 /dev/xvdc 15730688
xvdc6 : 0 15228928 /dev/xvdc 501760

Effettuare lo scan dei volumi fisici :
# pvscan

[root@localhost /]# pvscan
  PV /dev/sda3   VG VG_XenStorage-2963fe01-920a-b067-6880-3dcff67dea31   lvm2 [923.86 GB / 34.55 GB free]
  Total: 1 [923.86 GB] / in use: 1 [923.86 GB] / in no VG: 0 [0   ]

Attivare il volume group con:
vgchange -ay VG-name

 vgchange -ay VG_XenStorage-2963fe01-920a-b067-6880-3dcff67dea31

Montare il volume logico con i files ai quali si desidera accedere:

mount /dev/VG-name/LV-name  /tmp/mnt/

A questo punto è possibile accedere ai files in libertà.

Terminata l’azione sui files ricordarsi di ripristare la situaizone iniziale diversamente la Vm non può essere avviata. Allla procedura evidenziata sopra va aggiunta sola la rimozione del device mapping. Quindi evindeziando tutti i passaggi:

Smontare i volumi logici con

umount /tmp/c-boot
umount /tmp/c-root

controllare l’esistenza di ulteriori punti di mount con

 
df -a

se è stato fatto il device mapping rimuoverlo con

kpartx -d /dev/xvdc

sconnetere il VBD

xe vbd-unplug uuid=VBD-uuid

Eliminare il VBD

xe vbd-destroy uuid=VBD-uuid

ATTENZIONE

Prima di riprendere la normale attività e bene sempre controllare ancora una volta
l’esistenza di VBD facenti capo al dom0 con

xe vbd-list  uuid = uuid_dom0

se esistono ancora VBD non previsti procedere con l’unplug e il destroy del vbd come precisato sopra

 

Altre risorse nle blog:

 

Mount veloce della partizione LVM di una VM in XenServer 5.6

settembre 15, 2012 Lascia un commento

Obiettivo:  Accedere ai file systems di un VM fermata in XenServer 5.6 modificando e recuperando eventualemente files e directories.

Glossario:
dom0
  = dominio privilegiato.  E’  la Virtual Machine (VM) creata dall’Hypervisor di XenServe al boot. Il dominio privilegiato è  l’unico che ha accesso diretto all hardware e che si occupa di lanciare le altre VM .
domU = dominio non privilegiato .  Tutte le altre istanze di macchina virtuale (VM) in esecuzione diverse da dom0  sono dominioU:  viene creato un distinto dominio per ogni istanza.
VM : Virtual Machine, in XenServer è identificata da uno specifico uuid è ospitata in una Virtual Disk Image con un proprio vdi-uuid ed è connessa al dom0 grazie a un VBD con un suo vdb-uuid
VDI:  Virtual Disk Image, un immagine o file che rappresenta un hard disk virtual.
VDB: Virtual Block Device, un modo per connettere una VDI a una virtual machine
UUID: Universally unique identifier. Una stringa di caratteri che XenServer sistematicamente per idenficare in modo univoco un particolare oggetto.

Premetto ritengo che dovrebbe esistere un comando per effetturare il mount automatico del VDI di una VM halted in XenServer 5.6. Tuttavia non avendo trovato ancora lo stesso e trovandomi nella condizione di dover accedere ai files di una VM che non riparte ho osservato che utilizzando due console e sfruttando xe-edit-bootloader si può ottenre un accesso veloce alle partizioni.
Infatti xe-edit-bootloader per consentire l’edit del file grub.cfg crea il VBD del VDI della macchina virtuale. Effettua il plug del VBD dom0 e quindi il mount della partizione di boot in /var/run/. Come si può osservare dalla sequenza di operazioni svolta automaticamente

[root@localhost ~]# xe-edit-bootloader -n "ubuntu 12.04 LTS Server PV" -p 1
Creating dom0 VBD: c8b02acb-a63d-afdc-1504-335ccbee07c0
Plugging VBD: 
Waiting for /dev/xvda1: .. done
Mounting filesystem: done
Unplugging VBD: . done

questa l’intestazione di nano proposto in automatico per agire su grub.cfg che eivdenzia il punto di mount

GNU nano 1.3.12 File: /var/run/fix-grub-ecc801e0-f24c-4b31-a391-2e10bc9baeeb/boot/grub/grub.cfg

possiamo avere un ulteriore conferma del punto di mount della partizione di boot in /var/run utilizzando una seconda console collegata a XenServer e digitando

df -l 
/dev/xvda1 240972 43301 185230 19% /var/run/fix-grub-ecc801e0-f24c-4b31-a391-2e10bc9baeeb

all’uscita dalla fase di editing c’è il veloce unplug del VBD.

Pertanto se si desidera intervenire direttamente sulle partizioni di una VM fermata in modo veloce  è sufficiente evitare di uscire dalla fase di editing nella prima console e utilizzando la seconda console accedere alle partizioni presenti nella VDI della VM.

digitando fdisk -l nella seconda console è possibile osservare il dettaglio delle partizioni presenti nel VDI della VM con idicato il device in questo caso /dev/xvda.

[root@localhost grub]# fdisk -l
....
....
....

Disk /dev/xvda: 8589 MB, 8589934592 bytes
255 heads, 63 sectors/track, 1044 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/xvda1 * 1 32 248832 83 Linux
Partition 1 does not end on cylinder boundary.
/dev/xvda2 32 1045 8136705 5 Extended
/dev/xvda5 980 1045 522240 82 Linux swap / Solaris
/dev/xvda6 32 980 7614464 83 Linux

Ora finche il file grub.cfg rimarrà aperto sarà possibile montare le partizioni del device /dev/xvda con ad esempio

mkdir /mnt/xvda6 
mount /dev/svda6 /mnt/xvda6

quindi si potrà agire direttamente su files e directory.

Riassumendo un numero di comandi molto limitato imperniato su

xe-edit-bootloader -n "nome virtual machine" -p 1

-p indica la partizione di boot in genere assume valore 1 o 0

con fdisk -l si può osservare il device di tipo xvd[a-z] utilzzato

quindi il comando mount e ovviamente due sessioni

ATTENZIONE

Prima di riprendere la normale attività e bene sempre controllare ancora una volta
l’esistenza di VBD facenti capo al dom0 con

xe vbd-list  uuid = uuid_dom0

per determinare l’uuid dom0

xe vm-list | grep -B 1 -e Control

se esistono ancora VBD non previsti disconnettere il VBD (unplug destroy )

xe vbd-unplug uuid=VBD-uuid
xe vbd-unplug uuid=4e55fd78-d367-ccc0-dfc8-f06557080217

xe vbd-destroy uuid=VBD-uuid 
[root@localhost /]# xe vbd-destroy uuid=4e55fd78-d367-ccc0-dfc8-f06557080217
Categorie:Server Tag:, , , ,

Differenze tra PVM (paravirtualization ) e HVM ( Xen Full virtualization )

luglio 18, 2012 1 commento

PVM (Xen Paravirtualization – ParaVirtualized Machine ) rappresenta un approccio diverso alla virtualizzazione introdotto da Xen e ripreso da altri. In questo caso non c’è nessuna emulazione via software del hardware. E’ necessario tuttavia utilizzare dei kernel modficati. Ciò comporterà un’approccio più efficente, meno pesante e una velocità superiore.

HVM ( Xen Full virtualization – Hardware Virtualized Machine ) è una VM in cui si ha piena emulazione in software del hardware ( assistito  comunque dal hardware per poter essere efficace ).

Per Riconoscere/Distinguere una PV Machine da una HV Machine è possibile  ad es. controllare le opzioni di boot della VM e/o controllare  il risultato del comando lspci  .

Comando lspci :
PVM

$ lspci
~$

[non appare nulla ]
in una PVM non otteremo nessun elenco.  La VM non ha motherboard virtuale o altri dispositivi PCI  virtuali.

HVM

$ lspci
00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02)
00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II]
00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II]
00:01.2 USB Controller: Intel Corporation 82371SB PIIX3 USB [Natoma/Triton II] (rev 01)
...
...
$

In una HVM otteremo un elenco di dispositivi. Infatti una HVM avrà tutti dispositivi emulati dal sofware una  virtual motherboard, virtual PCI devices (IDE/SCSI block devices, hard disc, video board …)

Network boot :

Un altro modo per  riconoscere una HV  consiste controllare le propiertà della VM particolarmente le opzioni di boot.  Una  HVM supporta il  network boot, DVD and HDD boot. Mentre una  PV supporta solo  DVD or HDD boot  manca il network boot.  38. ( XenServer: Accedere a  VM >> “Properties” >> “Startup Options” )

Creare VM o PV machines

Per creare una HVM in XenServer utilizzare  l’opzione  “Other Install media
per creare  una PVM utilizzare il template specifico per la distribuzione prescelta e preferire l’installazione con il metodo URL

E possibile convertire VM da HVM to PVM dopo l’installaizone e vice-versa.

Windows non opera come  PV Machine.  Intel and AMD implemented an assistance for hardware emulation within their CPUs in order to make it feasible to emulation. E’ possibile caricare drivers in Windows che usino PV communications channel verso  disk/network/etc in Dom0 invece dei device emulati qemu PCI devices.

Risorse: