Parametri di Configurazione VM Xen xl.cfg

14 Aprile 2018 0 Di Alessandro Scamporrino

DESCRIZIONE
SINTASSI
OPZIONI
GUARDA ANCHE
FILE
RIFERIMENTI

DESCRIZIONE

La creazione di una VM (un dominio nella terminologia Xen, talvolta chiamata guest) con xl richiede la fornitura di un file di configurazione del dominio. Tipicamente, questi vivono in /etc/xen/DOMAIN.cfg, dove DOMAIN è il nome del dominio.

SINTASSI

Un file di configurazione del dominio è costituito da una serie di opzioni, specificate utilizzando KEY=VALUEcoppie.

Alcuni KEYsono obbligatori, alcuni sono opzioni generali che si applicano a qualsiasi tipo di ospite, mentre altri si riferiscono solo a specifici tipi di ospiti (ad es. PV o ospiti HVM).

A VALUEpuò essere uno di:

“STRINGA”: Una stringa, circondata da virgolette singole o doppie. Ma se STRING fa parte di SPEC_STRING, le virgolette dovrebbero essere omesse.
NUMERO: Un numero, in decimale, ottale (usando un 0prefisso) o esadecimale (usando un 0xprefisso) formato.
BOOLEAN: A NUMBERinterpretato come False( 0) o True(qualsiasi altro valore).
[VALUE, VALUE, …]: Una lista di VALUEs dei tipi di cui sopra. Le liste possono essere eterogenee e nidificate.

La semantica di ciascuno KEYdefinisce quale tipo di VALUEè richiesto.

Le coppie possono essere separate da una nuova riga o da un punto e virgola. Entrambe le seguenti sono valide:

  name="h0"
  type="hvm"

  name="h0"; type="hvm"

OPZIONI

Argomenti di configurazione obbligatori

La seguente chiave è obbligatoria per qualsiasi tipo di ospite.

name = “NAME”: Specifica il nome del dominio. I nomi dei domini esistenti su un singolo host devono essere unici.

Selezione del tipo di dominio guest

type = “pv”: Specifica che questo deve essere un dominio PV, adatto per l’hosting di sistemi operativi guest Xen-aware. Questo è l’impostazione predefinita.
digitare = “pvh”: Specifica che questo deve essere un dominio PVH. Questo è un guest HVM leggero senza un modello di dispositivo e senza molti dei dispositivi emulati disponibili per i guest HVM. Si noti che questa modalità richiede un kernel con conoscenza PVH.
digitare = “hvm”: Specifica che questo deve essere un dominio HVM. Cioè, un computer completamente virtualizzato con BIOS emulato, periferiche disco e rete, ecc.

Selezione del tipo di ospite deprecato

Si noti che l’opzione del builder viene deprecata a favore dell’opzione type.

builder = “generico”: Specifica che questo deve essere un dominio PV, adatto per l’hosting di sistemi operativi guest Xen-aware. Questo è l’impostazione predefinita.
builder = “HVM”: Specifica che questo deve essere un dominio HVM. Cioè, un computer completamente virtualizzato con BIOS emulato, periferiche disco e rete, ecc.

Opzioni generali

Le seguenti opzioni si applicano agli ospiti di qualsiasi tipo.

Assegnazione CPU

piscina = “CPUPOOLNAME”

Inserire i vCPU del guest nel pool CPU denominato.

vcpus = N

Avvia l’ospite con N vCPU inizialmente online.

maxvcpus = M

Consentire all’ospite di visualizzare un massimo di M vCPU. Quando si avvia il guest, se vcpus = N è minore di maxvcpus = M, allora le prime N vCPU verranno create online e il resto verrà creato offline.

cpu = “cpulist”

Elenco delle CPU host che il guest può utilizzare. Il valore predefinito non è affatto bloccato (più su questo sotto). A CPULISTpuò essere specificato come segue:

“tutti”

Per consentire a tutte le vCPU del guest di essere eseguite su tutte le CPU sull’host.

“0-3,5, ^ 1”

Per consentire a tutte le vCPU del guest di girare su CPU 0,2,3,5. È possibile combinare questo con “all”, che significa “tutti, ^ 7” risultati in tutte le vCPU del guest che possono essere eseguite su tutte le CPU dell’host eccetto CPU 7.

“Nodi: 0-3, ^ nodo: 2”

Per consentire a tutte le vCPU del guest di essere eseguite sulle CPU dai nodi NUMA 0,1,3 dell’host. Quindi, se le CPU 0-3 appartengono al nodo 0, le CPU 4-7 appartengono al nodo 1, le CPU 8-11 al nodo 2 e le CPU 12-15 al nodo 3, quanto sopra significherebbe che tutte le vCPU dell’ospite sarebbero consentite per eseguire su CPU 0-7,12-15.

È possibile combinare questa notazione con quella sopra. Ad esempio, “1, node: 1, ^ 6”, significa che tutte le vCPU del guest funzioneranno su CPU 1 e su tutte le CPU del nodo NUMA 1, ma non su CPU 6. Seguendo lo stesso esempio di cui sopra, che sarebbero CPU 1,4,5,7.

È anche possibile combinare questo con “all”, che significa “all, ^ node: 1” restituisce tutte le vCPU del guest in esecuzione su tutte le CPU sull’host, ad eccezione delle CPU appartenenti al nodo NUMA host 1.

[“2”, “3-8, ^ 5”]

Per richiedere una mappatura vCPU specifica. Ciò significa (in questo esempio), vCPU 0 del guest verrà eseguito sulla CPU 2 dell’host e vCPU 1 del guest verrà eseguito sulle CPU 3,4,6,7,8 dell’host (esclusa la CPU 5).

È possibile utilizzare anche notazioni più complesse, esattamente come descritto sopra. Quindi “tutto, ^ 5-8”, o solo “tutto”, o “nodo: 0, nodo: 2, ^ 9-11,18-20” sono tutti legali, per ogni elemento della lista.

Se questa opzione non viene specificata, non viene stabilita alcuna codifica vCPU su CPU e le vCPU del guest possono essere eseguite su tutte le CPU dell’host. Se questa opzione è specificata, l’intersezione della maschera pinning vCPU, fornita qui, e la maschera di affinità morbida, se fornita tramite cpus_soft = , viene utilizzata per calcolare l’affinità del nodo di dominio per l’allocazione di memoria.

cpus_soft = “cpulist”

Esattamente come cpus = , ma specifica affinità soft, piuttosto che pinning (hard affinity). Quando si utilizza il credit scheduler, ciò significa quali CPU preferiscono le vCPU del dominio.

A CPULISTè specificato esattamente come per cpus = , dettagliato in precedenza nel manuale.

Se questa opzione non viene specificata, le vCPU del guest non avranno alcuna preferenza per quanto riguarda le CPU host. Se viene specificata questa opzione, l’intersezione della maschera di affinità morbida, qui fornita, e il pinning vCPU, se fornito tramite cpus = , vengono utilizzati per calcolare l’affinità del nodo di dominio per l’allocazione della memoria.

Se questa opzione non è specificata (e cpus = non viene specificato neanche), libxl tenta automaticamente di posizionare il guest sul minor numero possibile di nodi. Un approccio euristico viene utilizzato per scegliere il miglior nodo (o insieme di nodi), con l’obiettivo di massimizzare le prestazioni per l’ospite e, allo stesso tempo, ottenere un utilizzo efficiente delle CPU e della memoria dell’host. In tal caso, l’affinità morbida di tutte le vCPU del dominio verrà impostata per ospitare le CPU appartenenti ai nodi NUMA scelti durante il posizionamento.

Per maggiori dettagli, vedi xl-numa-placement (7) .

Programmazione della CPU

cpu_weight = PESO

Un dominio con un peso di 512 avrà il doppio della CPU di un dominio con un peso di 256 su un host conteso. I pesi legali vanno da 1 a 65535 e il valore predefinito è 256. Onorato dagli scheduler di credito e credito2.

cap = N

Il cappuccio fissa facoltativamente la quantità massima di CPU che un dominio sarà in grado di consumare, anche se il sistema host ha cicli di CPU inattivi. Il limite è espresso come percentuale di una CPU fisica: 100 è 1 CPU fisica, 50 è metà CPU, 400 è 4 CPU, ecc. Il valore predefinito, 0, significa che non esiste un limite. Onorato dagli scheduler di credito e credito2.

NOTA : molti sistemi hanno funzionalità che ridimensionano la potenza di calcolo di una CPU che non è utilizzata al 100%. Questo può essere fatto nel sistema operativo, ma a volte può anche essere fatto sotto il sistema operativo, nel BIOS. Se imposti un limite in modo che i singoli core funzionino a meno del 100%, ciò potrebbe avere un impatto sulle prestazioni del tuo carico di lavoro oltre all’impatto del cap. Ad esempio, se il processore funziona a 2 GHz e si blocca una VM al 50%, il sistema di gestione dell’alimentazione può anche ridurre la velocità di clock a 1 GHz; l’effetto sarà che la tua VM ottiene il 25% della potenza disponibile (50% di 1 GHz) anziché il 50% (50% di 2 GHz). Se non stai ottenendo le prestazioni che ti aspetti, guarda le prestazioni e le opzioni di frequenza della CPU nel tuo sistema operativo e nel tuo BIOS.

Allocazione della memoria

memoria = MBYTE

Avviare l’ospite con MBYTES megabyte di RAM.

maxmem = MBYTE

Specifica la quantità massima di memoria che un ospite può mai vedere. Il valore di maxmem = deve essere uguale o maggiore di quello di memoria = .

In combinazione con memory = avvierà l’ospite “pre-ballooned”, se i valori di memory = e maxmem = differiscono. Un guest HVM “pre-ballooned” ha bisogno di un driver a palloncino, senza un driver a palloncino si bloccherà.

NOTA : A causa del modo in cui funziona il ballooning, l’ospite deve allocare memoria per tenere traccia delle pagine maxmem, indipendentemente dalla quantità di memoria effettivamente disponibile. Un guest con maxmem = 262144 e memoria = 8096 riporterà meno memoria disponibile per l’uso rispetto a un sistema con maxmem = 8096 memoria = 8096 a causa dell’overhead di memoria dovuto alla necessità di tenere traccia delle pagine non utilizzate.

Guest Virtual NUMA Configuration

vnuma = [VNODE_SPEC, VNODE_SPEC, …]

Specificare la configurazione NUMA virtuale con argomenti posizionali. L’ennesimo VNODE_SPEC nell’elenco specifica la configurazione dell’nnimo nodo virtuale.

Tieni presente che NUMA virtuale non è ancora supportato per gli ospiti PV, perché c’è un problema con la gestione delle istruzioni CPUID che influisce sulla NUMERA virtuale PV. Inoltre, gli ospiti con NUMA virtuale non possono essere salvati o migrati perché il flusso di migrazione non conserva le informazioni sul nodo.

Ogni VNODE_SPEC è una lista, che ha una forma di “[VNODE_CONFIG_OPTION, VNODE_CONFIG_OPTION, …]” (senza virgolette).

Ad esempio, vnuma = [[“pnode = 0”, “size = 512”, “vcpus = 0-4”, “vdistances = 10,20”]] significa che vnode 0 è mappato su pnode 0, ha 512 MB di ram, ha vcpus da 0 a 4, la distanza da se stessa è 10 e la distanza da vnode 1 è 20.

Ogni VNODE_CONFIG_OPTION è una KEY=VALUEcoppia quotata . Le VNODE_CONFIG_OPTION supportate sono (sono tutte obbligatorie al momento):

pnode = NUMERO

Specifica a quale nodo fisico questo nodo virtuale esegue il mapping.

size = MBYTE

Specifica la dimensione di questo nodo virtuale. La somma delle dimensioni della memoria di tutti i vnode diventerà maxmem = . Se maxmem = viene specificato separatamente, viene eseguito un controllo per assicurarsi che la somma di tutta la memoria di vnode corrisponda a maxmem = .

vcpus = “CPUSTRING”

Specifica quali vCPU appartengono a questo nodo. “CPUSTRING” è una stringa di valori numerici separati da una virgola. È possibile specificare un intervallo e / o una singola CPU. Un esempio potrebbe essere “vcpus = 0-5,8”, il che significa che hai specificato vCPU 0 a vCPU 5 e vCPU 8.

vdistances = NUMERO, NUMERO, …

Specifica la distanza virtuale da questo nodo a tutti i nodi (incluso se stesso) con argomenti posizionali. Ad esempio, “vdistance = 10,20” per vnode 0 indica che la distanza da vnode 0 a vnode 0 è 10, da vnode 0 a vnode 1 è 20. Il numero di argomenti forniti deve corrispondere al numero totale di vnode.

Normalmente è possibile utilizzare i valori da xl info -n o numactl –hardware per compilare l’elenco vdistances.

Azioni per eventi

on_poweroff = “ACTION”

Specifica cosa dovrebbe essere fatto con il dominio se si spegne. Le AZIONI sono:

distruggere: distruggi il dominio
ricomincia: distruggi il dominio e crea immediatamente un nuovo dominio con la stessa configurazione
rinomina-restart: rinominare il dominio che è terminato, quindi creare immediatamente un nuovo dominio con la stessa configurazione dell’originale
conserva: mantenere il dominio. Può essere esaminato e successivamente distrutto con xl destroy .
coredump-distruggere: scrivi un “coredump” del dominio in / var / lib / xen / dump / NAME e poi distruggi il dominio.
coredump-restart: scrivi un “coredump” del dominio in / var / lib / xen / dump / NAME e poi riavvia il dominio.
soft-reset: Ripristina tutte le interfacce Xen specifiche per il dominio HVM Xen-aware, consentendogli di ristabilire queste interfacce e continuare a eseguire il dominio. I guest HVM PV e non Xen-aware non sono supportati.

L’impostazione predefinita per on_poweroff è destroy .

on_reboot = “ACTION”

Azione da intraprendere se il dominio si arresta con un codice motivo che richiede un riavvio. L’impostazione predefinita è il riavvio .

on_watchdog = “ACTION”

Azione da eseguire se il dominio si arresta a causa di un timeout del watchdog Xen. L’impostazione predefinita è distruggere .

on_crash = “ACTION”

Azione da intraprendere se il dominio si arresta in modo anomalo. L’impostazione predefinita è distruggere .

on_soft_reset = “ACTION”

Azione da intraprendere se il dominio esegue un “soft reset” (ad esempio kexec ). L’impostazione predefinita è soft-reset .

Direct Kernel Boot

L’avvio diretto del kernel consente di avviare i guest con un kernel e un initrd memorizzati su un filesystem disponibile per la macchina fisica host, consentendo il passaggio diretto degli argomenti della riga di comando. L’avvio del kernel diretto del guest PV è supportato. L’avvio diretto del kernel guest HVM è supportato con alcune limitazioni (è supportato quando si usa qemu-xen e il BIOS predefinito ‘seabios’, ma non è supportato in caso di utilizzo di stubdom-dm e del vecchio ‘rombios’.)

kernel = “percorso”: Carica il file specificato come immagine del kernel.
ramdisk = “percorso”: Carica il file specificato come ramdisk.
cmdline = “STRING”: Aggiungi STRING alla riga di comando del kernel. (Nota: il significato di questo è specifico ospite). Può sostituire root = “STRING” con extra = “STRING” ed è preferito. Quando cmdline = “STRING” è impostato, root = “STRING” e extra = “STRING” saranno ignorati.
root = “STRING”: Aggiungi root = STRING alla riga di comando del kernel (Nota: il significato di questo è specifico per gli ospiti).
in più = “STRING”: Aggiungi STRING alla riga di comando del kernel. (Nota: il significato di questo è specifico ospite).

Kernel Boot non diretto

L’avvio del kernel non diretto consente di avviare i guest con un firmware. Questo può essere utilizzato da tutti i tipi di ospiti, sebbene la selezione delle opzioni sia diversa a seconda del tipo di ospite.

Questa opzione fornisce la flessibilità di lasciare che l’ospite decida quale kernel desidera avviare, evitando di dover attirare il file system guest nel dominio del toolstack.

Opzioni ospite PV

Firmware = “pvgrub32 | pvgrub64”

Avvia un guest utilizzando una versione para-virtualizzata di grub che viene eseguita all’interno dell’ospite. Il testimone dell’ospite deve essere noto, in modo che sia possibile selezionare la versione corretta di pvgrub.

Si noti che xl si aspetta di trovare i binari pvgrub32.bin e pvgrub64.bin in / usr / local / lib / xen / boot .

Opzioni ospite HVM

firmware = “bios”: Avviare il guest utilizzando il firmware BIOS predefinito, che dipende dal modello di dispositivo scelto.
Firmware = “UEFI”: Avviare il guest utilizzando il firmware UEFI predefinito, attualmente OVMF.
firmware = “seabios”: Avviare il guest utilizzando il firmware del BIOS SeaBIOS.
firmware = “rombios”: Avviare il guest utilizzando il firmware del BIOS ROMBIOS.
Firmware = “ovmf”: Avviare il guest utilizzando il firmware UEFI OVMF.
Firmware = “PERCORSO”: Carica il file specificato come firmware per il guest.

Opzioni per gli ospiti PVH

Al momento non sono disponibili firmware per gli ospiti PVH, dovrebbero essere avviati utilizzando il metodo di avvio diretto del kernel o l’ opzione del bootloader .

pvshim = BOOLEAN

Se avviare questo guest come guest PV all’interno di un contenitore PVH. Ad esempio, l’ospite sperimenterà un ambiente fotovoltaico, ma le estensioni hardware del processore sono utilizzate per separare il suo spazio indirizzo per mitigare l’attacco Meltdown (CVE-2017-5754).

Il valore predefinito è falso.

pvshim_path = “PERCORSO”

Lo shim PV è un eseguibile simile al firmware appositamente costruito, costruito dall’albero dei sorgenti dell’hypervisor. Questa opzione specifica di utilizzare uno shim non predefinito. Ignorato se pvhsim è falso.

pvshim_cmdline = “STRING”

Riga di comando per lo spessore. L’impostazione predefinita è “pv-shim console = xen, pv”. Ignorato se pvhsim è falso.

pvshim_extra = “STRING”

Argomenti della riga di comando aggiuntivi per lo shim. Se fornito, aggiunto al valore per pvshim_cmdline. L’impostazione predefinita è vuota. Ignorato se pvhsim è falso.

Altre opzioni

uuid = “UUID”

Specifica l’UUID del dominio. Se non specificato, verrà generato un nuovo UUID univoco.

seclabel = “LABEL”

Assegna un’etichetta di sicurezza XSM a questo dominio.

init_seclabel = “LABEL”

Specifica un’etichetta di sicurezza XSM utilizzata temporaneamente per questo dominio durante la sua creazione. L’etichetta XSM del dominio verrà modificata sull’esecuzione seclabel (specificata da seclabel ) una volta completata la compilazione, prima di annullare la compilazione del dominio. Con una politica di sicurezza opportunamente costruita (come nomigrate_t nella policy di esempio), questa può essere usata per costruire un dominio la cui memoria non è accessibile al dominio del toolstack.

max_grant_frames = NUMERO

Specificare il numero massimo di frame di concessione che il dominio può avere. Questo valore controlla quante pagine il dominio è in grado di concedere l’accesso ad altri domini, necessari ad esempio per il funzionamento dei dispositivi paravirtualizzati. L’impostazione predefinita è impostabile tramite xl.conf (5) .

max_maptrack_frames = NUMERO

Specificare il numero massimo di frame di tracciatrici di concessione che il dominio può avere. Questo valore controlla il numero di pagine di domini esterni accessibili tramite il meccanismo di concessione da parte di questo dominio. Il valore predefinito è impostabile tramite xl.conf (5) .

nomigrate = BOOLEAN

Disabilita la migrazione di questo dominio. Ciò abilita alcune altre funzionalità che sono incompatibili con la migrazione. Attualmente questo è limitato all’abilitazione del flag di funzionalità TSC invariante nei risultati CPUID quando TSC non viene emulato.

driver_domain = BOOLEAN

Specifica che questo dominio è un dominio del driver. Questo abilita alcune funzionalità necessarie per eseguire un dominio driver.

device_tree = PATH

Specificare un albero dei dispositivi parziale (compilato tramite il compilatore dell’albero dei dispositivi). Tutto sotto il nodo “/ passthrough” verrà copiato nell’albero del dispositivo guest. Per comodità, anche il nodo “/ alias” viene copiato per consentire all’utente di definire alias che possono essere utilizzati dal kernel guest.

Data la complessità della verifica della validità di una struttura di dispositivi, questa opzione deve essere utilizzata solo con una struttura di dispositivi attendibili.

Si noti che l’albero del dispositivo parziale dovrebbe evitare l’uso del phandle 65000 che è riservato dal toolstack.

dispositivi

Le seguenti opzioni definiscono i dispositivi paravirtuali, emulati e fisici che l’ospite conterrà.

disk = [“DISK_SPEC_STRING”, “DISK_SPEC_STRING”, …]

Specifica i dischi (entrambi i dischi emulati e i dispositivi di blocco virtuali Xen) che devono essere forniti all’ospite e quali oggetti sull’host devono mappare. Vedi Configurazione dei Dischi Virtuali delle VM Xen per maggiori dettagli.

vif = [“NET_SPEC_STRING”, “NET_SPEC_STRING”, …]

Specifica le interfacce di rete (entrambe le schede di rete emulate e le interfacce virtuali Xen) che devono essere fornite all’ospite. Vedi Configurazione delle Interfacce di Rete delle VM Xen per maggiori dettagli.

vtpm = [“VTPM_SPEC_STRING”, “VTPM_SPEC_STRING”, …]

Specifica il modulo Virtual Trusted Platform da fornire al guest. Vedi xen-vtpm (7) per maggiori dettagli.

Ogni VTPM_SPEC_STRING è un elenco di KEY=VALUEimpostazioni separate da virgola dal seguente elenco:

backend = domain-id: Specifica il nome o l’ID del dominio di back-end. Questo valore è richiesto! Se questo dominio è un ospite, il back-end dovrebbe essere impostato sul nome di dominio vTPM. Se questo dominio è un vTPM, il back-end dovrebbe essere impostato sul nome di dominio del gestore vTPM.
uuid = UUID: Specifica l’UUID di questo dispositivo vTPM. L’UUID viene utilizzato per identificare in modo univoco il dispositivo vTPM. È possibile crearne uno usando il programma uuidgen (1) sui sistemi unix. Se non specificato, un nuovo UUID verrà generato casualmente ogni volta che si avvia il dominio. Se si tratta di un dominio vTPM, è necessario specificare un valore. Il valore è facoltativo se si tratta di un dominio guest.

p9 = [“9PFS_SPEC_STRING”, “9PFS_SPEC_STRING”, …]

Crea una connessione Xen 9pfs per condividere un filesystem dal backend al frontend.

Ogni 9PFS_SPEC_STRING è un elenco di KEY=VALUEimpostazioni separate da virgole , dal seguente elenco:

tag = STRING: Tag 9pfs per identificare la condivisione del filesystem. Il tag è necessario sul lato ospite per il suo montaggio.
security_model = “none”: Solo “nessuno” è supportato oggi, il che significa che i file vengono archiviati utilizzando le stesse credenziali di quelli che hanno nel guest (nessuna proprietà utente squash o rimappatura).
path = STRING: Percorso del file system sul back-end da esportare.
backend = domain-id: Specificare il nome o l’ID del dominio di back-end, predefinito su dom0.

pvcalls = [“backend = domain-id”, …]

Crea una connessione pvcalls Xen per gestire le richieste pvcalls dal frontend al backend. Può essere usato come un modello di rete alternativo. Per ulteriori informazioni sul protocollo, consultare https://xenbits.xen.org/docs/unstable/misc/pvcalls.html.

vfb = [“VFB_SPEC_STRING”, “VFB_SPEC_STRING”, …]

Specifica i dispositivi framebuffer paravirtuali che devono essere forniti al dominio.

Questa opzione non controlla la scheda grafica emulata presentata a un guest HVM. Vedi Dispositivo grafico VGA emulato di seguito per come configurare il dispositivo emulato. Se le opzioni del dispositivo grafico VGA emulato vengono utilizzate in una configurazione guest PV, xl acquisirà vnc , vnclisten , vncpasswd , vncdisplay , vncunused , sdl , opengl e keymap per costruire il dispositivo framebuffer paravirtual per il guest.

Ogni VFB_SPEC_STRING è un elenco di KEY=VALUEimpostazioni separate da virgole , dal seguente elenco:

vnc = BOOLEAN

Consentire l’accesso al display tramite il protocollo VNC. Questo abilita le altre impostazioni relative a VNC. Il valore predefinito è 1 (abilitato).

vnclisten = INDIRIZZO [: DISPLAYNUM]

Specifica l’indirizzo IP e facoltativamente il numero del display VNC da usare.

Nota: se si specifica il numero del display qui, non si dovrebbe usare l’ opzione vncdisplay .

vncdisplay = DISPLAYNUM

Specifica il numero del display VNC da utilizzare. Il numero di porta TCP effettivo sarà DISPLAYNUM + 5900.

Nota: non utilizzare questa opzione se si imposta DISPLAYNUM nell’opzione vnclisten .

vncunused = BOOLEAN

Richiede che l’installazione del display VNC cerchi una porta TCP libera da utilizzare. È possibile accedere alla visualizzazione effettiva utilizzata con xl vncviewer .

vncpasswd = PASSWORD

Specifica la password per il server VNC. Se la password è impostata su una stringa vuota, l’autenticazione sul server VNC verrà disabilitata, consentendo a qualsiasi utente di connettersi.

sdl = BOOLEAN

Specifica che il display deve essere presentato tramite una finestra X (utilizzando Simple DirectMedia Layer). Il valore predefinito è 0 (non abilitato).

display = DISPLAY

Specifica la visualizzazione X Window da utilizzare quando viene utilizzata l’ opzione sdl .

XAUTHORITY = XAUTHORITY

Specifica il percorso del file di autorizzazione X che deve essere utilizzato per connettersi al server X quando viene utilizzata l’ opzione sdl .

opengl = BOOLEAN

Abilita l’accelerazione OpenGL del display SDL. Solo le macchine degli effetti che utilizzano device_model_version = “qemu-xen-traditional” e solo se il modello del dispositivo è stato compilato con il supporto OpenGL. Il valore predefinito è 0 (disabilitato).

keymap = LANG

Configura la mappa dei tasti da utilizzare per la tastiera associata a questo display. Se il metodo di input non supporta facilmente i codici chiave non elaborati (ad esempio, questo è spesso il caso quando si utilizza VNC), questo ci consente di mappare correttamente le chiavi di input in keycode visti dall’ospite. I valori specifici accettati sono definiti dalla versione del modello di dispositivo che si sta utilizzando. Vedere le Keymap qui sotto o consultare la manpage qemu (1) . L’impostazione predefinita è en-us .

channel = [“CHANNEL_SPEC_STRING”, “CHANNEL_SPEC_STRING”, …]

Specifica i canali virtuali da fornire al guest. Un canale è un flusso di byte bidirezionale a larghezza di banda ridotta, che assomiglia a un collegamento seriale. Gli usi tipici dei canali includono la trasmissione della configurazione della VM dopo l’avvio e la segnalazione agli agenti guest. Si prega di vedere xen-pv-channel (7) per maggiori dettagli.

Ogni CHANNEL_SPEC_STRING è un elenco di KEY=VALUEimpostazioni separate da virgole . Gli spazi bianchi iniziali e finali vengono ignorati sia in KEY che in VALUE. Né KEY né VALUE possono contenere ‘,’, ‘=’ o ‘”‘. I valori definiti sono:

backend = domain-id

Specifica il nome o l’ID del dominio di back-end. Questo parametro è facoltativo. Se questo parametro viene omesso, verrà assunto il dominio toolstack.

name = NOME

Specifica il nome per questo dispositivo. Questo parametro è obbligatorio! Questo dovrebbe essere un nome noto per un’applicazione specifica (ad esempio agente ospite) e dovrebbe essere utilizzato dal frontend per connettere l’applicazione al dispositivo del canale destro. Non esiste un registro formale dei nomi dei canali, quindi gli autori delle applicazioni sono incoraggiati a rendere i loro nomi univoci includendo il nome del dominio e un numero di versione nella stringa (ad es. Org.mydomain.guestagent.1).

collegamento = CONNESSIONE

Specifica come verrà implementato il back-end. Sono disponibili le seguenti opzioni:

PRESA: Il backend collegherà un socket di dominio Unix (al percorso fornito da path = PATH ), ascolta e accetta connessioni. Il backend eseguirà il proxy dei dati tra il canale e il socket connesso.
PTY: Il backend creerà un pty e dati proxy tra il canale e il dispositivo master. Il comando xl channel-list può essere usato per scoprire il dispositivo slave assegnato.

RDM = “RDM_RESERVATION_STRING”

Solo HVM / x86! Specifica le informazioni sulla memoria dei dispositivi riservati (RDM), necessaria per abilitare il passthrough del dispositivo robusto. Un esempio di RDM sta segnalando attraverso la struttura ACPI Reserved Memory Region Reporting (RMRR) sulla piattaforma x86.

RDM_RESERVATION_STRING è un elenco di KEY=VALUEimpostazioni separato da virgole , dal seguente elenco:

strategia = STRING

Attualmente esiste un solo tipo valido, ovvero “host”.

ospite

Se impostato su “host” significa che tutta la memoria del dispositivo riservata su questa piattaforma deve essere controllata per riservare regioni nello spazio degli indirizzi di questa VM. Questo parametro RDM globale consente all’utente di specificare esplicitamente le regioni riservate, e l’utilizzo di “host” include tutte le regioni riservate riportate su questa piattaforma, che è utile quando si esegue hotplug.

Di default questo non è impostato in modo da non controllare tutti gli RDM. Invece, controlliamo l’RDM specifico per un dato dispositivo se assegniamo questo tipo di dispositivo.

Nota: questa opzione non è raccomandata a meno che non ci si possa assicurare che non esistano conflitti.

Ad esempio, stai cercando di impostare “memory = 2800” per allocare memoria su una determinata VM, ma la piattaforma possiede due regioni RDM come:

Dispositivo A [sbdf_A]: RMRR region_A: base_addr ac6d3000 end_address ac6e6fff

Dispositivo B [sbdf_B]: RMRR region_B: base_addr ad800000 end_address afffffff

In questo caso di conflitto,

# 1. Se la strategia è impostata su “host”, ad esempio:

rdm = “strategia = host, policy = strict” o rdm = “strategy = host, policy = relaxed”

significa che tutti i conflitti saranno gestiti secondo la politica introdotta dalla politica come descritto di seguito.

# 2. Se la strategia non è impostata, ma

pci = [‘sbdf_A, rdm_policy = xxxxx’]

significa che verrà gestito un solo conflitto di region_A in base alla politica introdotta da rdm_policy = STRING come descritto nelle opzioni pci .

la politica = STRING

Specifica come gestire i conflitti quando si riserva la memoria del dispositivo già prenotato nello spazio degli indirizzi del guest.

rigoroso

Specifica che in caso di conflitto non risolto non è possibile creare la VM o che il dispositivo associato non può essere collegato nel caso di hotplug.

rilassato

Specifica che in caso di conflitto non risolto è possibile creare la VM, ma può causare l’arresto anomalo della VM se un dispositivo pass-through accede a RDM. Ad esempio, il driver GFX di Windows IGD accede sempre alle regioni RDM in modo da provocare un arresto anomalo della macchina virtuale.

Nota: questo può essere sovrascritto dall’opzione rdm_policy nella configurazione del dispositivo pci .

usbctrl = [“USBCTRL_SPEC_STRING”, “USBCTRL_SPEC_STRING”, …]

Specifica i controller USB creati per questo guest.

Ogni USBCTRL_SPEC_STRING è un elenco di KEY=VALUEimpostazioni separate da virgole , dal seguente elenco:

type = TIPO

Specifica il tipo di controller USB.

pv

Specifica un back-end PVUSB basato sul kernel.

Qusb

Specifica un backend PVUSB basato su QEMU.

Modello del dispositivo

Specifica un controller USB emulato da QEMU. Apparirà come un dispositivo PCI nel guest.

auto

Determina se è installato un backend basato sul kernel. Se questo è il caso, verrà usato pv , altrimenti verrà usato qusb . Per i domini HVM sarà selezionato devicemodel .

Questa opzione è l’impostazione predefinita.

version = VERSION

Specifica la versione del controller USB. I valori possibili includono 1 (USB 1.1), 2 (USB 2.0) e 3 (USB 3.0). L’impostazione predefinita è 2 (USB 2.0). Il valore 3 (USB 3.0) è disponibile solo per il tipo di dispositivo virtuale .

ports = PORTE

Specifica il numero totale di porte del controller USB. Il numero massimo è 31. Il valore predefinito è 8. Con il tipo devicemodel il numero di porte è più limitato: un controller USB1.1 ha sempre 2 porte, un controller USB2.0 ha sempre 6 porte e un controller USB3.0 può avere fino a 15 porte.

Gli ID controller USB iniziano da 0. In linea con le specifiche USB, tuttavia, le porte su un controller iniziano da 1.

ESEMPIO

usbctrl = [“version = 1, ports = 4”, “version = 2, ports = 8”]

Il primo controller è USB1.1 e ha:

controller id = 0 e porte 1,2,3,4.

Il secondo controller è USB 2.0 e ha:

controller id = 1 e porte 1,2,3,4,5,6,7,8.

usbdev = [“USBDEV_SPEC_STRING”, “USBDEV_SPEC_STRING”, …]

Specifica i dispositivi USB da collegare al guest all’avvio.

Ogni USBDEV_SPEC_STRING è un elenco di KEY=VALUEimpostazioni separate da virgole , dal seguente elenco:

type = hostdev

Specifica il tipo di dispositivo USB. Attualmente è supportato solo “hostdev”.

hostbus = BusNum

Specifica il busnum del dispositivo USB dal punto di vista dell’host.

hostAddr = devnum

Specifica il valore del dispositivo USB dal punto di vista dell’host.

regolatore = CONTROLLER

Specifica l’ID del controller USB, a cui è collegato il dispositivo USB.

Se non viene specificato alcun controller, verrà utilizzato un controller disponibile: verrà utilizzata la combinazione di porte. Se non ci sono controller disponibili: combinazioni di porte, verrà creato un nuovo controller.

port = PORT

Specifica la porta USB a cui è collegato il dispositivo USB. L’ opzione port è valida solo quando è specificata l’ opzione controller .

pci = [“PCI_SPEC_STRING”, “PCI_SPEC_STRING”, …]

Specifica i dispositivi PCI host da passare a questo guest. Ogni PCI_SPEC_STRING ha la forma di [DDDD:] BB: DD.F [@VSLOT], KEY = VALUE, KEY = VALUE, … dove:

[DDDD:] BB: DD.F

Identifica il dispositivo PCI dal punto di vista dell’host nella sintassi domain ( DDDD ), Bus ( BB ), Device ( DD ) e Function ( F ). Questo è lo stesso schema utilizzato nell’output di lspci (1) per il dispositivo in questione.

Nota: per impostazione predefinita lspci (1) ometterà il dominio ( DDDD ) se è zero ed è facoltativo anche qui. È possibile specificare la funzione ( F ) come * per indicare tutte le funzioni.

@VSLOT

Specifica lo slot virtuale in cui il guest vedrà questo dispositivo. Questo è equivalente al DD che l’ospite vede. In un ospite DDDD e BB sono 0000:00.

permissive = BOOLEAN

Per impostazione predefinita, pciback consente solo agli ospiti PV di scrivere valori “conosciuti e sicuri” nello spazio di configurazione PCI, allo stesso modo QEMU (sia qemu-xen che qemu-xen-tradizionale) impone lo stesso vincolo ai guest HVM. Tuttavia, per funzionare correttamente, molti dispositivi richiedono la scrittura in altre aree dello spazio di configurazione. Questa opzione indica al backend (pciback o QEMU) di consentire tutte le scritture allo spazio di configurazione PCI di questo dispositivo da questo dominio.

Questa opzione deve essere abilitata con cautela: dà all’ospite un controllo molto maggiore sul dispositivo, che può avere implicazioni di sicurezza o stabilità. Si consiglia di abilitare questa opzione solo per macchine virtuali affidabili sotto il controllo dell’amministratore.

msitranslate = BOOLEAN

Specifica che la traduzione MSI-INTx deve essere attivata per il dispositivo PCI. Se abilitata, la traduzione MSI-INTx abiliterà sempre l’MSI sul dispositivo PCI indipendentemente dal fatto che il guest utilizzi INTx o MSI. Alcuni driver di dispositivo, come NVIDIA, rilevano un’incoerenza e non funzionano quando questa opzione è abilitata. Pertanto il valore predefinito è false (0).

cogliere = BOOLEAN

Dice a xl di tentare automaticamente di riassegnare un dispositivo a pciback se non è già assegnato.

ATTENZIONE: Se si imposta questa opzione, xl riassegnerà volentieri un dispositivo di sistema critico, come una rete o un controller del disco utilizzato da dom0 senza conferma. Si prega di usare con cura.

power_mgmt = BOOLEAN

(Solo HVM) Specifica che la VM deve essere in grado di programmare gli stati di risparmio energetico D0-D3hot per il dispositivo PCI. L’impostazione predefinita è false (0).

rdm_policy = STRING

(Solo HVM / x86) È uguale all’impostazione del criterio all’interno dell’opzione rdm ma solo specifico per un determinato dispositivo. L’impostazione predefinita è “rilassata”.

Nota: questo annullerebbe l’ opzione globale rdm .

pci_permissive = BOOLEAN

Cambia il valore predefinito di permissivo per tutti i dispositivi PCI passati attraverso questa VM. Vedi permissivo sopra.

pci_msitranslate = BOOLEAN

Cambia il valore predefinito di msitranslate per tutti i dispositivi PCI passati a questa VM. Vedi msitranslate sopra.

pci_seize = BOOLEAN

Cambia il valore predefinito di grippaggio per tutti i dispositivi PCI passati attraverso questa VM. Vedi cogliere sopra.

pci_power_mgmt = BOOLEAN

(Solo HVM) Modifica il valore predefinito di power_mgmt per tutti i dispositivi PCI passati a questa VM. Vedi power_mgmt sopra.

gfx_passthru = BOOLEAN | “STRING”

Abilita passthrough PCI per dispositivi grafici. Questa opzione rende una scheda grafica PCI assegnata la scheda grafica principale nella VM. La scheda grafica emulata QEMU è disabilitata e la console VNC per la VM non avrà alcun output grafico. Tutti gli output grafici, inclusi i messaggi del BIOS QEMU di avvio dalla VM, andranno alle uscite fisiche della scheda grafica fisica passata.

Il dispositivo PCI della scheda grafica da passare viene scelto con l’ opzione pci , esattamente nello stesso modo in cui viene eseguito un normale passthrough / assegnazione del dispositivo Xen PCI. Si noti che gfx_passthru non esegue alcun tipo di condivisione della GPU, quindi è possibile assegnare la GPU a una sola VM alla volta.

gfx_passthru abilita anche vari intervalli di memoria VGA legacy, BAR, MMIO e ioports da passare alla VM, poiché sono necessari per il corretto funzionamento di cose come VGA BIOS, modalità testo, VBE, ecc.

L’abilitazione dell’opzione gfx_passthru copia anche il BIOS video della scheda grafica fisica nella memoria del guest ed esegue il VBIOS nel guest per inizializzare la scheda grafica.

La maggior parte delle schede grafiche richiede modifiche specifiche del fornitore per il passthrough della grafica correttamente funzionante. Vedi la pagina wiki XenVGAPassthroughTestedAdapters http://wiki.xen.org/wiki/XenVGAPassthroughTestedAdapters per le schede grafiche attualmente supportate da gfx_passthru .

gfx_passthru è attualmente supportato sia con il modello del dispositivo qemu-xen-tradizionale sia con il modello del dispositivo qemu-xen upstream.

Quando viene fornito come booleano, l’ opzione gfx_passthru disabilita il passthrough della scheda grafica o abilita il rilevamento automatico.

Quando viene fornito come stringa, l’ opzione gfx_passthru descrive il tipo di dispositivo da abilitare. Si noti che questo comportamento è supportato solo con il modello di dispositivo qemu-xen upstream. Con qemu-xen-tradizionale IGD (Intel Graphics Device) viene sempre assunto e le opzioni diverse da autodetect o IGD esplicito provocheranno un errore.

Attualmente, i valori validi per l’opzione sono:

0: Disabilita il passthrough PCI dei dispositivi grafici.
1 , “predefinito”: Abilita il passthrough PCI del dispositivo grafico e rileva automaticamente il tipo di dispositivo che viene utilizzato.
“IG D”: Abilita il passthrough PCI del dispositivo grafico, ma impone il tipo di dispositivo a Intel Graphics Device.

Si noti che alcune schede grafiche (schede AMD / ATI, ad esempio) non richiedono necessariamente l’ opzione gfx_passthru , quindi è possibile utilizzare il normale passthrough Xen PCI per assegnare la scheda grafica come scheda grafica secondaria alla VM. La scheda grafica emulata QEMU rimane la scheda grafica principale e l’uscita VNC è disponibile dall’adattatore principale emulato QEMU.

Ulteriori informazioni sulla funzione Xen gfx_passthru sono disponibili su XenVGAPassthrough http://wiki.xen.org/wiki/XenVGAPassaggi alla pagina wiki.

rdm_mem_boundary = MBYTE

Numero di megabyte da impostare per un limite durante il controllo dei conflitti RDM.

Quando RDM è in conflitto con la RAM, RDM è probabilmente disseminato sull’intero spazio della RAM. Avere più voci RDM potrebbe peggiorare questo e portare a un layout di memoria complicato. Qui stiamo cercando di capire una soluzione semplice per evitare di rompere il layout esistente. Quando si verifica un conflitto,

    #1. Above a predefined boundary
        - move lowmem_end below the reserved region to solve the conflict;

    #2. Below a predefined boundary
        - Check if the policy is strict or relaxed.
        A "strict" policy leads to a fail in libxl.
        Note that when both policies are specified on a given region,
        "strict" is always preferred.
        The "relaxed" policy issues a warning message and also masks this
        entry INVALID to indicate we shouldn't expose this entry to
        hvmloader.

Il valore predefinito è 2048.

dtdev = [“DTDEV_PATH”, “DTDEV_PATH”, …]

Specifica i nodi dell’albero del dispositivo host da passare a questo guest. Ogni DTDEV_PATH è un percorso assoluto nell’albero del dispositivo.

ioports = [“IOPORT_RANGE”, “IOPORT_RANGE”, …]

Consentire al guest di accedere a porte I / O legacy specifiche. Ogni IOPORT_RANGE viene fornito in formato esadecimale e può essere un intervallo, ad esempio 2f8-2ff(incluso) o una singola porta I / O, ad es 2f8.

Si consiglia di utilizzare questa opzione solo per macchine virtuali affidabili sotto il controllo dell’amministratore.

iomem = [“IOMEM_START, NUM_PAGES [@GFN]”, “IOMEM_START, NUM_PAGES [@GFN]”, …]

Consenti ai domini auto-convertiti di accedere a specifiche pagine di memoria I / O hardware.

IOMEM_START è un numero di pagina fisico. NUM_PAGES è il numero di pagine, a partire da START_PAGE , per consentire l’accesso a. GFN specifica il numero del frame ospite in cui inizierà la mappatura nello spazio degli indirizzi del guest. Se GFN non è specificato, la mappatura verrà eseguita utilizzando IOMEM_START come inizio nello spazio degli indirizzi del guest, pertanto, per impostazione predefinita, eseguirà un mapping 1: 1. Tutti questi valori devono essere forniti in formato esadecimale.

Si noti che IOMMU non verrà aggiornato con i mapping specificati con questa opzione. Pertanto questa opzione non deve essere utilizzata per passare attraverso dispositivi IOMMU protetti.

Si consiglia di utilizzare questa opzione solo per macchine virtuali affidabili sotto il controllo dell’amministratore.

irqs = [NUMERO, NUMERO, …]

Permetti a un ospite di accedere a specifici IRQ fisici.

Si consiglia di utilizzare questa opzione solo per macchine virtuali affidabili sotto il controllo dell’amministratore.

Se la console vuart è abilitata, irq 32 è riservato per questo. Vedi “vuart =” uart “” per sapere come abilitare la console di vuart.

max_event_channels = N

Limita l’ospite a utilizzare al massimo N canali evento (interrupt PV). Gli ospiti utilizzano le risorse hypervisor per ciascun canale evento che utilizzano.

Il valore predefinito di 1023 dovrebbe essere sufficiente per gli ospiti tipici. Il valore massimo dipende da ciò che l’ospite supporta. Gli ospiti che supportano il canale di eventi ABI basato su FIFO supportano fino a 131.071 canali di eventi. Gli altri ospiti sono limitati a 4095 (64 bit x86 e ARM) o 1023 (32 bit x86).

vdispl = [“VDISPL_SPEC_STRING”, “VDISPL_SPEC_STRING”, …]

Specifica i dispositivi di visualizzazione virtuale da fornire al guest.

Ogni VDISPL_SPEC_STRING è un elenco di KEY=VALUEimpostazioni separate da virgole , dal seguente elenco:

backend=DOMAIN

Specifica il nome o l’ID del dominio di back-end. Se non specificato, viene usato Domain-0.

be-alloc=BOOLEAN

Indica se il back-end può essere un provider / allocatore di buffer per questo dominio. Vedi il protocollo di visualizzazione per i dettagli.

connectors=CONNECTORS

Specifica i connettori virtuali per il dispositivo nel seguente formato <id>: <W> x <H>; <id>: <W> x <H> … dove:

id: ID connettore stringa. Spazio, i simboli delle virgole non sono ammessi.
W: Larghezza connettore in pixel.
H: Altezza del connettore in pixel.

ESEMPIO

connettori = ID0: 1920×1080; id1: 800×600; ID2: 640×480

dm_restrict = BOOLEAN

Limita il modello del dispositivo dopo l’avvio, per limitare le conseguenti vulnerabilità della sicurezza in qemu.

Con questa funzione abilitata, un compromesso del modello di dispositivo, attraverso tale vulnerabilità, non fornirà un attacco di escalation di privilegi sull’intero sistema.

Questa funzione è un’anteprima della tecnologia . Ci sono alcune limitazioni significative:

È improbabile che funzioni per gli ospiti di PV o per gli utenti che utilizzano backsqdisk per i loro dispositivi a blocchi.
Devi avere un qemu abbastanza nuovo. In particolare, se il tuo qemu non ha il commit xen: restrict: usa xentoolcore_restrict_all la richiesta di restrizione sarà silenziosamente inefficace!
I meccanismi utilizzati non sono efficaci contro i problemi di negazione del servizio. Un qemu compromesso può probabilmente compromettere o addirittura impedire il corretto funzionamento dell’intero sistema (per lo meno, ma non solo, attraverso l’esaurimento delle risorse).
Non è noto se la protezione sia efficace quando viene migrato un dominio.
Alcune funzioni di gestione dei domini non funzionano. Ad esempio, l’inserimento di cdrom fallirà.
Si dovrebbe dire vga="none". Domini con schede grafiche stdvga che non funzionano. I domini con cirrus vga sembrano funzionare.
È necessario creare utenti per qemu da eseguire come.Idealmente, metti da parte un intervallo di 32752 UID (da N a N + 32751) e crea un utente il cui nome è xen-qemuuser-range-base e il cui uid è N e il cui gid è un semplice guru non privilegiato. libxl userà uno di questi utenti per ogni domino.In alternativa, puoi creare xen-qemuuser-domid $ domid per ogni $ domid da 1 a 32751 compreso, o xen-qemuuser-shared (nel qual caso i diversi ospiti non saranno protetti l’uno dall’altro).
Non ci sono contromisure adottate contro il riutilizzo dello stesso utente unix (uid) per i domini successivi, anche se vengono creati gli utenti di domen $ xen-qemuuser-domid $ . Quindi un dominio passato con lo stesso domino potrebbe essere in grado di interferire con i domini futuri. Forse, anche dopo un riavvio.
Un qemu compromesso sarà in grado di leggere i file leggibili a livello mondiale nel sistema operativo dom0.
A causa di queste limitazioni, questa funzionalità, sebbene possa migliorare la sicurezza, non dovrebbe essere invocata. Eventuali ulteriori limitazioni scoperte nella versione corrente nonverranno gestite tramite il processo di sicurezza di Xen Project.
In futuro, mentre miglioriamo questa funzionalità per migliorare la sicurezza, potremmo interrompere la compatibilità con le versioni precedenti.

Opzioni specifiche per gli ospiti paravirtualizzate (PV)

Le seguenti opzioni si applicano solo agli ospiti paravirtuali (PV).

bootloader = “PROGRAMMA”

Esegui PROGRAMper trovare l’immagine del kernel e il ramdisk da usare. Normalmente PROGRAMsarebbe pygrub, che è un’emulazione di grub / grub2 / syslinux. Sia il kernel che il bootloader devono essere specificati per gli ospiti PV.

bootloader_args = [“ARG”, “ARG”, …]

Aggiungi ARG agli argomenti nel programma del bootloader . In alternativa, se l’argomento è una stringa semplice, sarà diviso in parole nello spazio bianco (questa seconda opzione è deprecata) .

e820_host = BOOLEAN

Seleziona se esporre l’host e820 (mappa della memoria) all’ospite tramite l’e820 virtuale. Quando questa opzione è falsa (0), lo spazio degli indirizzi pseudo-fisici guest è costituito da una singola area RAM contigua. Quando viene specificata questa opzione, l’e820 virtuale riflette invece l’host e820 e contiene gli stessi fori PCI. La quantità totale di RAM rappresentata dalla mappa di memoria è sempre la stessa, questa opzione configura solo come è strutturata.

L’esposizione dell’host e820 all’ospite dà al kernel guest l’opportunità di mettere da parte la parte richiesta del suo spazio di indirizzo pseudo-fisico per fornire lo spazio degli indirizzi per mappare i dispositivi PCI passanti. Dipende dal sistema operativo guest se questa opzione è richiesta, in particolare è richiesta quando si utilizza un kernel Linux (“pvops”) mainline. Questa opzione è impostata su true (1) se tutti i dispositivi passthrough PCI sono configurati e false (0) in caso contrario. Se non si configurano dispositivi passthrough durante la creazione del dominio ma si prevede di utilizzare dispositivi hotplug in un secondo momento, è necessario impostare questa opzione. Viceversa se il tuo particolare kernel guest non richiede questo comportamento, allora è sicuro che questo sia abilitato ma potresti comunque disabilitarlo.

Opzioni specifiche per gli ospiti completamente virtualizzate (HVM)

Le seguenti opzioni si applicano solo ai guest completamente virtualizzati (HVM).

Dispositivo di avvio

boot = “STRING”

Specifica il dispositivo virtuale emulato da cui avviare.

I valori possibili sono:

c: Disco rigido.
d: CD ROM.
n: Rete / PXE.

Nota: è possibile fornire più opzioni e verranno tentate nell’ordine in cui vengono fornite, ad esempio per l’avvio da CD-ROM, ma ricadendo sul disco rigido è possibile specificarlo come dc .

L’impostazione predefinita è cd , ovvero provare a eseguire l’avvio dal disco rigido per primo, ma tornare al CD-ROM.

Tipo di controller del disco emulato

hdtype = STRING

Specifica il tipo di disco rigido.

I valori possibili sono:

ide: Se viene specificata questa modalità, xl aggiunge un controller IDE emulato, che è adatto anche per i sistemi operativi precedenti.
AHCI: Se viene specificata questa modalità, xl aggiunge un controller di disco ich9 in modalità AHCI e lo utilizza con QEMU upstream per emulare i dischi anziché l’IDE. Riduce il tempo di avvio, ma potrebbe non essere supportato di default nei sistemi operativi precedenti, ad esempio Windows XP.

L’impostazione predefinita è ide .

paging

Le seguenti opzioni controllano i meccanismi utilizzati per virtualizzare la memoria ospite. I valori predefiniti sono selezionati per fornire i migliori risultati per i casi comuni, pertanto è opportuno lasciare normalmente queste opzioni non specificate.

HAP = BOOLEAN: Attiva o disattiva il “paging hardware assistito” (l’uso della funzione della tabella di pagine nidificate nell’hardware). Questa funzione è chiamata EPT (Extended Page Tables) di Intel e NPT (Nested Page Tables) o RVI (Rapid Virtualisation Indexing) di AMD. Se disattivato, Xen eseguirà il guest nella modalità “tabella delle pagine shadow” in cui verranno aggiornati gli aggiornamenti della tabella delle pagine degli ospiti e / o gli svuotamenti di TLB, ecc. L’utilizzo di HAP è l’impostazione predefinita quando disponibile.
oos = BOOLEAN: Attiva o disattiva “offline syncable”. Quando si esegue in modalità tabella pagine shadow, gli aggiornamenti della tabella di pagine del guest potrebbero essere differiti come specificato nei manuali di architettura Intel / AMD. Tuttavia, questo potrebbe esporre bug inaspettati nel guest o trovare bug in Xen, quindi è possibile disabilitare questa funzionalità. L’uso di tabelle di pagine fuori sincrono, quando Xen lo ritiene appropriato, è l’impostazione predefinita.
shadow_memory = MBYTE: Numero di megabyte da riservare per l’ombreggiamento delle pagine pagabili degli ospiti (che agiscono efficacemente come una cache delle pagine tradotte) o da utilizzare per lo stato HAP. Di default questo è 1 MB per guest vCPU più 8 KB per MB di RAM guest. Normalmente non è necessario regolare questo valore. Tuttavia, se non si utilizza il paging con hardware assistito (ovvero se si utilizza la modalità shadow) e il carico di lavoro del guest è costituito da un numero molto elevato di processi simili, l’aumento di questo valore potrebbe migliorare le prestazioni.

Funzionalità del processore e della piattaforma

Le seguenti opzioni consentono di nascondere o mostrare diverse funzionalità del processore e della piattaforma dal punto di vista dell’utente. Questo può essere utile quando si eseguono sistemi operativi guest più datati che potrebbero comportarsi in modo anomalo se confrontati con funzionalità più moderne. In generale, dovresti accettare le impostazioni predefinite per queste opzioni, ove possibile.

bios = “STRING”

Seleziona il firmware virtuale esposto al guest. Per impostazione predefinita, viene effettuata un’ipotesi basata sul modello del dispositivo, ma a volte può essere utile richiederne uno diverso, come UEFI.

rombios: Carica ROMBIOS, un BIOS compatibile x86 a 16 bit. Questo è usato di default quando device_model_version = qemu-xen-traditional . Questa è l’unica opzione BIOS supportata quando device_model_version = qemu-xen-traditional . Questo è il BIOS usato da tutte le versioni precedenti di Xen.
seabios: Carica SeaBIOS, un BIOS compatibile x86 a 16 bit. Questo è usato di default con device_model_version = qemu-xen.
ovmf: Carica OVMF, un firmware UEFI standard dal progetto Tianocore. Richiede device_model_version = qemu-xen.

bios_path_override = “PERCORSO”

Sostituire il percorso del BLOB da utilizzare come BIOS. Il blob fornito qui DEVE essere coerente con il bios = che hai specificato. Normalmente non è necessario specificare questa opzione.

Questa opzione non ha alcun effetto se si utilizza bios = “rombios” o device_model_version = “qemu-xen-traditional” .

pae = BOOLEAN

Nascondere o esporre le estensioni degli indirizzi fisici IA32. Queste estensioni consentono a un sistema operativo guest a 32 bit di accedere a oltre 4 GB di RAM. L’attivazione di PAE abilita anche altre funzionalità come NX. PAE è richiesto se si desidera eseguire un sistema operativo guest a 64 bit. In generale, è necessario lasciarlo abilitato e consentire al sistema operativo guest di scegliere se utilizzare o meno il PAE. (Solo X86)

acpi = BOOLEAN

Esporre le tabelle ACPI (Advanced Configuration and Power Interface) dal firmware virtuale al sistema operativo guest. ACPI è richiesto dalla maggior parte dei moderni sistemi operativi guest. Questa opzione è abilitata di default e di solito dovresti ometterla. Tuttavia, potrebbe essere necessario disabilitare ACPI per la compatibilità con alcuni sistemi operativi guest. Questa opzione è vera per x86 mentre è falsa per ARM di default.

acpi_s3 = BOOLEAN

Includere lo stato di alimentazione S3 (suspend-to-ram) nella tabella ACPI del firmware virtuale. True (1) per impostazione predefinita.

acpi_s4 = BOOLEAN

Include lo stato di alimentazione S4 (suspend-to-disk) nella tabella ACPI del firmware virtuale. True (1) per impostazione predefinita.

acpi_laptop_slate = BOOLEAN

Includere il dispositivo di commutazione della modalità laptop / ardesia di Windows nella tabella ACPI del firmware virtuale. False (0) per impostazione predefinita.

apic = BOOLEAN

(solo x86) Includere le informazioni relative a APIC (Advanced Interrupt Controller programmabile) nelle tabelle firmware / BIOS su un singolo guest del processore. Ciò causa l’esportazione delle tabelle MP (multiprocessore) e PIR (PCI Interrupt Routing) dal firmware virtuale. Questa opzione non ha alcun effetto su un guest con più CPU virtuali poiché devono sempre includere queste tabelle. Questa opzione è abilitata per impostazione predefinita e in genere dovresti ometterla, ma potrebbe essere necessario disabilitare queste tabelle del firmware quando si utilizzano determinati sistemi operativi guest precedenti. Queste tabelle sono state sostituite dai costrutti più recenti all’interno delle tabelle ACPI.

nx = BOOLEAN

(solo x86) Nasconde o espone la funzionalità No-eXecute. Ciò consente a un sistema operativo guest di mappare le pagine in modo tale da non poter essere eseguite, il che può migliorare la sicurezza. Questa opzione richiede che anche PAE sia abilitato.

HPET = BOOLEAN

(solo x86) Abilita o disabilita HPET (Timer eventi ad alta precisione). Questa opzione è abilitata di default e di solito dovresti ometterla. Potrebbe essere necessario disabilitare HPET per migliorare la compatibilità con i sistemi operativi guest.

altp2m = “MODE”

(solo x86) Specifica la modalità di accesso alla capacità p2m alternativa. Alternate-p2m consente a un guest di gestire più “viste di memoria” fisiche di p2m guest (a differenza di un singolo p2m). Questa opzione può essere utile se si desidera accedere / controllare / isolare l’accesso a specifiche pagine di memoria fisica del guest accessibili dall’ospite, ad esempio per l’introspezione della memoria del dominio o per l’isolamento / controllo di accesso della memoria tra componenti all’interno di un singolo dominio ospite. Questa opzione è disabilitata di default.

I valori validi sono i seguenti:

Disabilitato: Altp2m è disabilitato per il dominio (predefinito).
misto: La modalità mista consente l’accesso all’interfaccia altp2m sia per gli strumenti interni che per quelli esterni.
esterno: Consente l’accesso alla funzionalità p2m alternativa da strumenti con privilegi esterni.
limitato: Consente un accesso limitato alla capacità p2m alternativa, es. concedere all’ospite l’accesso solo per abilitare / disabilitare le funzioni VMFUNC e #VE.

altp2mhvm = BOOLEAN

Abilita o disabilita l’accesso guest HVM alla funzionalità p2m alternativa. Alternate-p2m consente a un guest di gestire più “viste di memoria” fisiche di p2m guest (a differenza di un singolo p2m). Questa opzione è disabilitata per impostazione predefinita ed è disponibile solo per i domini HVM. Questa opzione può essere utile se si desidera accedere / controllare / isolare l’accesso a specifiche pagine di memoria fisica del guest accessibili dall’ospite, ad esempio per introspezione della memoria del dominio HVM o per l’isolamento / controllo di accesso della memoria tra componenti all’interno di un singolo dominio ospite HVM. Questa opzione è deprecata, utilizzare invece l’opzione “altp2m”.

Nota : sebbene l’opzione “altp2mhvm” sia deprecata, le applicazioni legacy per i sistemi x86 continueranno a funzionare usando questo.

nestedhvm = BOOLEAN

Abilita o disabilita l’accesso degli ospiti alle funzionalità di virtualizzazione dell’hardware, ad esempio consente a un sistema operativo guest di funzionare anche come hypervisor. Si consiglia questa opzione se si desidera eseguire un altro hypervisor (inclusa un’altra copia di Xen) all’interno di un guest Xen o per supportare un sistema operativo guest che utilizza estensioni di virtualizzazione dell’hardware (ad esempio, la modalità di compatibilità di Windows XP su un sistema operativo Windows più moderno). Questa opzione è disabilitata di default.

cpuid = “LIBXL_STRING” o cpuid = [“XEND_STRING”, “XEND_STRING”]

Configurare il valore restituito quando un guest esegue l’istruzione CPUID. Sono riconosciute due versioni della sintassi di configurazione: libxl e xend.

La sintassi libxl è un elenco separato da virgole di coppie chiave = valore, preceduto dalla parola “host”. Alcuni tasti hanno un valore numerico, tutti gli altri prendono un singolo carattere che descrive cosa fare con il bit della funzione.

Valori possibili per un singolo bit di funzionalità: ‘1’ -> forza il bit corrispondente a 1 ‘0’ -> forza a 0 ‘x’ -> Ottieni un valore sicuro (passa attraverso e maschera con la politica di default) ‘k’ – > passare il valore del bit dell’host ‘s’ -> come ‘k’ ma conservare attraverso save / restore e migration (non implementato)

Nota: quando si specifica cpuid per hypervisor leaves (gruppo principale 0x4000xxxx) vengono elaborati solo gli 8 bit più bassi del registro EAX 0x4000xx00, gli altri vengono ignorati (questi 8 bit indicano il numero massimo di foglie dell’hypervisor).

Elenco delle chiavi che assumono un valore: apicida brandid clflush family localapicid maxleaf maxhvleaf model nc proccount procpkg stepping

Elenco dei tasti che assumono un carattere: 3DNow 3dnowext 3DNowPrefetch ABM ACPI ADX aes altmovcr8 apic Arat AVX AVX2 avx512-4fmaps avx512-4vnniw avx512bw avx512cd avx512dq avx512er avx512f avx512ifma avx512pf avx512vbmi avx512vl BMI1 bmi2 clflushopt clfsh Clwb cmov cmplegacy cmpxchg16 cmpxchg8 CMT cntxid dca de ds dscpl dtes64 erms est extapic f16c ffxsr fma fma4 fpu fsgsbase fxsr hle htt hypervisor ia64 ibs invpcid invtsc lahfsahf lm lwp mca mce misalignsse mmx mmxext monitor movbe mpx msr mtrr nodeid nx ospke osvw osxsave pae pagina1gb ppa pcid pclmulqdq pdcm perfctr_core perfctr_nb pge pku popcnt pse pse36 psn rdrand rdseed rdtscp rtm sha skinit smap smep sx sse sse2 sse3 sse4.1 sse4.2 sse4_1 sse4_2 sse4a ssse3 svm svm_decode svm_lbrv svm_npt svm_nrips svm_pausefilt svm_tscrate svm_vmcbclean syscall sysenter tbm tm tm2 topoext tsc tsc-deadline tsc_adjust umip vme vmx wdt x2apic xop xsave xtpr

La sintassi xend è una lista di valori sotto forma di ‘leafnum: register = bitstring, register = bitstring’ “leafnum” è la funzione richiesta, “register” è il registro di risposta per modificare “bitstring” rappresenta tutti i bit nel registro, la sua lunghezza deve essere di 32 caratteri. Ogni carattere successivo rappresenta un bit meno significativo, i possibili valori sono elencati sopra nella sezione libxl.

Esempio per nascondere due funzionalità dal guest: ‘tm’, che è il bit # 29 in EDX, e ‘pni’ (SSE3), che è il bit # 0 in ECX:

xend: [“1: ecx = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx0, edx = xx0xxxxxxxxxxxxxxxxxxxxxxxxxxxxx”]

libxl: “host, tm = 0, sse3 = 0”

Maggiori informazioni sull’istruzione CPUID sono disponibili nei manuali del processore e su Wikipedia: http://en.wikipedia.org/wiki/CPUID

acpi_firmware = “STRING”

Specifica un percorso per un file che contiene tabelle firmware ACPI aggiuntive da passare in un guest. Il file può contenere diverse tabelle nel loro modulo AML binario concatenato insieme. Ogni tabella descrive la sua lunghezza in modo tale da non richiedere ulteriori informazioni. Queste tabelle verranno aggiunte alla serie di tabelle ACPI nel guest. Nota che le tabelle esistenti non possono essere sovrascritte da questa funzione. Ad esempio, questo non può essere usato per sovrascrivere tabelle come DSDT, FADT, ecc.

smbios_firmware = “STRING”

Specifica un percorso per un file che contiene strutture di firmware SMBIOS aggiuntive da passare in un guest. Il file può contenere una serie di strutture predefinite DMTF che sostituiranno le impostazioni predefinite interne. Non tutte le strutture predefinite possono essere sovrascritte, solo i seguenti tipi: 0, 1, 2, 3, 11, 22, 39. Il file può anche contenere un numero qualsiasi di strutture SMBIOS definite dal fornitore (tipo 128 – 255). Poiché le strutture SMBIOS non presentano la loro dimensione complessiva, ogni voce nel file deve essere preceduta da un numero intero 32b che indica la dimensione della seguente struttura.

ms_vm_genid = “OPZIONE”

Fornire un ID di generazione VM al guest.

L’ID generazione VM è un numero casuale a 128 bit che può essere utilizzato da un guest per determinare se il guest è stato ripristinato da uno snapshot precedente o clonato.

È necessario per i controller di dominio Microsoft Windows Server 2012 (e successivi).

Le opzioni valide sono:

creare: Genera un ID generazione VM casuale ogni volta che il dominio viene creato o ripristinato.
nessuna: Non fornire un ID di generazione VM.

Vedi anche “ID macchina virtuale” di Microsoft: http://www.microsoft.com/en-us/download/details.aspx?id=30707

Guest Virtual Time Controls

tsc_mode = “MODE”

(solo x86) Specifica come deve essere fornito al guest TSC (contatore di data e ora). La specifica di questa opzione come numero è deprecata.

Le opzioni sono:

predefinito

Guest rdtsc / p viene eseguito in modo nativo quando la monotonicità può essere garantita ed emulata in altro modo (con frequenza ridimensionata se necessario).

Se un contenitore HVM in modalità TSC predefinita viene creato su un host che fornisce un TSC host costante, la frequenza TSC ospite sarà la stessa dell’host. Se successivamente viene eseguita la migrazione a un altro host che fornisce TSC host costante e supporta il rapporto TSC SVM / AMD SVM di Intel VMX TSC, la frequenza TSC ospite sarà la stessa prima e dopo la migrazione e guest rdtsc / p verrà eseguito in modo nativo dopo la migrazione come bene

always_emulate

Guest rdtsc / p viene sempre emulato e il TSC virtuale sembrerà incrementare (kernel e utente) ad una frequenza fissa di 1 GHz, indipendentemente dalla frequenza HZ pCPU o dallo stato di alimentazione. Sebbene esista un sovraccarico associato all’emulazione, questo NON influirà sulle prestazioni della CPU sottostante.

nativo

Guest rdtsc / p viene sempre eseguito in modo nativo (nessuna garanzia di monotonicità / frequenza). Guest rdtsc / p viene emulato a frequenza nativa se non supportato da h / w, altrimenti eseguito in modo nativo.

native_paravirt

Come nativo , eccetto che Xen gestisce il registro TSC_AUX in modo che il guest possa determinare quando si è verificato un ripristino / migrazione e presuppone che il guest ottenga / usi un meccanismo simile a pvclock per regolare la monotonia e le variazioni di frequenza.

Se un contenitore HVM nella modalità TSC native_paravirt può eseguire sia guest rdtsc che guest rdtscp in modo nativo, la frequenza TSC ospite verrà determinata in modo simile a quella della modalità TSC predefinita .

Si prega di consultare xen-tscmode (7) per maggiori informazioni su questa opzione.

localtime = BOOLEAN

Imposta l’orologio in tempo reale sull’ora locale o su UTC. False (0) per impostazione predefinita, ovvero impostato su UTC.

rtc_timeoffset = secondi

Imposta l’offset dell’orologio in tempo reale in secondi. Nessun offset (0) per impostazione predefinita.

vpt_align = BOOLEAN

Specifica che i timer periodici della piattaforma virtuale devono essere allineati per ridurre gli interrupt degli ospiti. L’abilitazione di questa opzione può ridurre il consumo energetico, soprattutto quando un ospite utilizza valori di frequenza di interruzione del timer (HZ). Il valore predefinito è true (1).

timer_mode = “MODE”

Specifica la modalità per i timer virtuali. I valori validi sono i seguenti:

delay_for_missed_ticks: Ritardo per mancate zecche. Non anticipare un tempo di vCPU oltre il tempo di consegna corretto per gli interrupt che sono stati persi a causa della preventiva. Fornire interrupt persi quando la vCPU è riprogrammata e far avanzare gradualmente il tempo virtuale della vCPU per ciascuno.
no_delay_for_missed_ticks: Nessun ritardo per le zecche perse. Come sopra, le interruzioni mancate vengono consegnate, ma il tempo ospite tiene sempre traccia del tempo di wallclock (cioè, reale) mentre lo fa. Questo è l’impostazione predefinita.
no_missed_ticks_pending: Nessun interruzione persa viene sospesa. Invece, per garantire che le zecche siano consegnate ad una velocità diversa da zero, se rileviamo tick mancanti, l’allarme tick interno non viene disabilitato se il vCPU viene preempito durante il successivo periodo di tick.
one_missed_tick_pending: In attesa di un tick spuntato. Gli interrupt persi sono collassati insieme e consegnati come un “ticchettio in ritardo”. L’ora dell’ospite tiene sempre traccia del tempo di wallclock (cioè, reale).

Layout di memoria

mmio_hole = MBYTE

Specifica la dimensione del foro MMIO sotto 4GiB. Valido solo per device_model_version = “qemu-xen” .

Non può essere inferiore a 256. Non può essere maggiore di 3840.

Conosciuto, un valore elevato è 3072.

Supporto per la paravirtualizzazione degli ospiti HVM

Le seguenti opzioni consentono alle funzionalità Paravirtualizzate (come i dispositivi) di essere esposte al sistema operativo guest in un guest HVM. L’utilizzo di queste funzionalità richiede un supporto guest specifico ma, quando disponibili, si tradurrà in un miglioramento delle prestazioni.

xen_platform_pci = BOOLEAN

Abilita o disabilita il dispositivo PCI della piattaforma Xen. La presenza di questo dispositivo virtuale abilita un sistema operativo guest (soggetto alla disponibilità di driver adatti) per utilizzare le funzionalità di paravirtualizzazione come dischi e dispositivi di rete, ecc. Abilitare questi driver migliora le prestazioni ed è fortemente raccomandato quando disponibile. I driver PV sono disponibili per vari sistemi operativi tra cui HVM Linux http://wiki.xen.org/wiki/XenLinuxPVonHVMdrivers e Microsoft Windows http://wiki.xen.org/wiki/XenWindowsGplPv .

L’impostazione xen_platform_pci = 0 con il device_model predefinito “qemu-xen” richiede almeno QEMU 1.6.

viridian = [“GROUP”, “GROUP”, …] o viridian = BOOLEAN

I gruppi di chiarimenti compatibili con Microsoft Hyper-V (AKA viridian) esposti al guest. I seguenti gruppi di chiarimenti possono essere specificati:

base: Questo gruppo include MSR di Hypercall, MSR dell’indice di processore virtuale e MSR di accesso APIC. Queste illuminazioni possono migliorare le prestazioni di Windows Vista e Windows Server 2008 in poi e si consiglia vivamente di impostare questa opzione per tali ospiti. Questo gruppo è anche un pre-requisito per tutti gli altri. Se è disabilitato, è un errore tentare di abilitare qualsiasi altro gruppo.
freq: Questo gruppo incorpora gli MSR di frequenza TSC e APIC. Queste illuminazioni possono migliorare le prestazioni di Windows 7 e Windows Server 2008 R2 in poi.
time_ref_count: Questo gruppo include il contatore di riferimento del tempo di partizione MSR. Questa illuminazione può migliorare le prestazioni di Windows 8 e Windows Server 2012 in poi.
reference_tsc: Questo set incorpora il MSR TSC Partition Reference. Questa illuminazione può migliorare le prestazioni di Windows 7 e Windows Server 2008 R2 in poi.
hcall_remote_tlb_flush: Questo set incorpora l’uso di hypercall per lo svuotamento TLB remoto. Questa illuminazione può migliorare le prestazioni dei guest Windows in esecuzione su host con livelli più elevati di contesa della CPU (fisica).
apic_assist: Questo set incorpora l’uso della pagina di assistenza APIC per evitare l’EOI dell’APIC locale. Questa illuminazione può migliorare le prestazioni degli ospiti che fanno uso di vettori upcall per canale evento per-vCPU. Nota che questa illuminazione non avrà alcun effetto se il guest sta usando gli interrupt pubblicati da APICv.
crash_ctl: Questo gruppo incorpora gli MSR di crash control. Queste illuminazioni consentono a Windows di scrivere informazioni sugli arresti anomali in modo che possano essere registrate da Xen.
default: Questo è un valore speciale che abilita il gruppo predefinito di gruppi, che è attualmente i gruppi base , freq , time_ref_count , apic_assist e crash_ctl .
tutti: Questo è un valore speciale che abilita tutti i gruppi disponibili.

I gruppi possono essere disabilitati anteponendo il nome con ‘!’. Ad esempio, per abilitare tutti i gruppi tranne freq , specificare:

viridian = [“all”, “! freq”]

Per i dettagli sugli illuminamenti, consultare la versione più recente delle specifiche funzionali di livello superiore dell’hypervisor di Microsoft.

Gli illuminamenti dovrebbero essere innocui per le altre versioni di Windows (anche se non daranno alcun vantaggio) e la maggior parte degli altri sistemi operativi non Windows. Tuttavia, è noto che sono incompatibili con altri sistemi operativi e in alcune circostanze possono impedire l’utilizzo delle interfacce di paravirtualizzazione di Xen per gli ospiti di HVM.

L’opzione viridian può essere specificata come booleana. Un valore di true (1) è equivalente alla lista [“default”], e un valore di false (0) è equivalente a una lista vuota.

Dispositivo grafico VGA emulato

Le seguenti opzioni controllano le caratteristiche del dispositivo grafico emulato. Molte di queste opzioni si comportano in modo simile alla chiave equivalente in VFB_SPEC_STRING per la configurazione dei dispositivi del frame buffer virtuale (vedere sopra).

videoram = MBYTE

Imposta la quantità di RAM che la scheda video emulata conterrà, il che a sua volta limiterà le risoluzioni e le profondità di bit che saranno disponibili.

Quando si utilizza il modello del dispositivo qemu-xen-tradizionale, la quantità predefinita e minima di RAM video per stdvga è di 8 MB, che è sufficiente per es. 1600×1200 a 32 bpp. Per il modello di dispositivo qemu-xen upstream, il valore predefinito e minimo è 16 MB.

Quando si utilizza la scheda grafica Cirrus emulata ( vga = “cirrus” ) e il modello del dispositivo qemu-xen-tradizionale, la quantità di RAM video è fissata a 4 MB, che è sufficiente per 1024×768 a 32 bpp. Per il modello di dispositivo qemu-xen upstream, il valore predefinito e minimo è 8 MB.

Per QXL vga, sia il valore predefinito che il minimo sono 128 MB. Se il videoregistratore è impostato su un valore inferiore a 128 MB, verrà generato un errore.

stdvga = BOOLEAN

Fornisce una scheda VGA standard con VBE (estensioni VESA BIOS) come dispositivo grafico emulato. Se il tuo ospite supporta VBE 2.0 o successivo (ad es. Windows XP in poi), dovresti abilitare questo. stdvga supporta più ram video e risoluzioni più grandi di Cirrus. L’impostazione predefinita è false (0) che significa emulare una scheda VGA GD5446 di Cirrus Logic. Questa opzione è deprecata, usa invece vga = “stdvga” .

vga = “STRING”

Seleziona la scheda video emulata. Le opzioni sono: none , stdvga , cirrus e qxl . Il valore predefinito è cirrus .

In generale, QXL dovrebbe funzionare con il protocollo Spice Remote Display per l’accelerazione e in questo caso è necessario un driver QXL nel guest. QXL può anche funzionare con il protocollo VNC, ma sarà come una scheda VGA standard senza accelerazione.

vnc = BOOLEAN

Consentire l’accesso al display tramite il protocollo VNC. Questo abilita le altre impostazioni relative a VNC. L’impostazione predefinita è (1) abilitata.

vnclisten = “INDIRIZZO [: DISPLAYNUM]”

Specifica l’indirizzo IP e, facoltativamente, il numero del display VNC da utilizzare.

vncdisplay = DISPLAYNUM

Specifica il numero del display VNC da utilizzare. Il numero di porta TCP effettivo sarà DISPLAYNUM + 5900.

vncunused = BOOLEAN

Richiede che l’installazione del display VNC cerchi una porta TCP libera da utilizzare. È possibile accedere alla visualizzazione effettiva utilizzata con xl vncviewer .

vncpasswd = “PASSWORD”

Specifica la password per il server VNC. Se la password è impostata su una stringa vuota, l’autenticazione sul server VNC verrà disabilitata consentendo a qualsiasi utente di connettersi.

keymap = “LANG”

sdl = BOOLEAN

Specifica che il display deve essere presentato tramite una finestra X (utilizzando Simple DirectMedia Layer). L’impostazione predefinita è (0) non abilitata.

opengl = BOOLEAN

nographic = BOOLEAN

Abilita o disabilita il dispositivo grafico virtuale. L’impostazione predefinita è di fornire un dispositivo grafico VGA ma questa opzione può essere utilizzata per disabilitarlo.

Spice Graphics Support

Le seguenti opzioni controllano le funzionalità di SPICE.

spezie = BOOLEAN

Consentire l’accesso al display tramite il protocollo SPICE. Questo abilita le altre impostazioni relative a SPICE.

spicehost = “INDIRIZZO”

Specifica l’indirizzo dell’interfaccia da ascoltare se specificato, altrimenti qualsiasi interfaccia.

spiceport = NUMERO

Specifica la porta da ascoltare dal server SPICE se SPICE è abilitato.

spicetls_port = NUMERO

Specifica la porta sicura da ascoltare dal server SPICE se SPICE è abilitato. Deve essere fornito almeno uno di spiceport o spicetls_port se SPICE è abilitato.

Nota: le opzioni che dipendono da spicetls_port non sono state supportate.

spicedisable_ticketing = BOOLEAN

Abilita i client a connettersi senza specificare una password. Se disabilitato, è necessario impostare spicepasswd . L’impostazione predefinita è (0) false.

spicepasswd = “PASSWORD”

Specificare la password che viene utilizzata dai client per stabilire una connessione.

spiceagent_mouse = BOOLEAN

Se l’agente SPICE viene utilizzato per la modalità mouse client. L’impostazione predefinita è (1) true.

spicevdagent = BOOLEAN

Abilita il vdagent SPICE. SPICE vdagent è un componente opzionale per migliorare l’esperienza utente e svolgere attività di gestione orientate ai clienti. Le sue caratteristiche includono: modalità mouse client (non è necessario afferrare il mouse dal client, nessun ritardo del mouse), regolazione automatica della risoluzione dello schermo, copia e incolla (testo e immagine) tra il client e l’ospite. Richiede inoltre il funzionamento del servizio vdagent installato sul sistema operativo guest. L’impostazione predefinita è (0) disabilitata.

spice_clipboard_sharing = BOOLEAN

Consente la condivisione degli Appunti SPICE (copia / incolla). Richiede che spicevdagent sia abilitato. L’impostazione predefinita è (0) false.

spiceusbredirection = NUMERO

Abilita il reindirizzamento USB SPICE. Crea un numero di canali di reindirizzamento USB per reindirizzare fino a 4 dispositivi USB dal client SPICE al QEMU del guest. Richiede un controller USB e, se non definito, aggiungerà automaticamente un controller USB 2.0. L’impostazione predefinita è (0) disabilitata.

spice_image_compression = “compressione”

Specifica quale compressione dell’immagine deve essere utilizzata da SPICE (se specificata), altrimenti verrà utilizzato il valore predefinito di QEMU. Si prega di consultare la documentazione della propria versione QEMU per maggiori dettagli.

Le opzioni disponibili sono: auto_glz, auto_lz, quic, glz, lz, off .

spice_streaming_video = “VIDEO”

Specifica quali impostazioni di streaming video devono essere utilizzate da SPICE (se specificato), altrimenti verrà utilizzato il valore predefinito di QEMU.

Le opzioni disponibili sono: filtro, tutto, spento .

Hardware emulato vario

serial = [“DEVICE”, “DEVICE”, …]

Reindirizzare le porte seriali virtuali su DEVICE s. Si prega di consultare l’ opzione -serial nella manpage qemu (1) per i dettagli delle opzioni DEVICE valide . L’impostazione predefinita è vc in modalità grafica e stdio se viene utilizzato nographics = 1 .

Il modulo serial = DEVICE è anche accettato per la retrocompatibilità.

soundhw = “DISPOSITIVO”

Seleziona la scheda audio virtuale da esporre all’ospite. I dispositivi validi sono definiti dalla configurazione del modello del dispositivo, per i dettagli consultare la manpage qemu (1) . L’impostazione predefinita non è l’esportazione di alcun dispositivo audio.

usb = BOOLEAN

Abilita o disabilita un bus USB emulato nel guest.

usbversion = NUMERO

Specifica il tipo di un bus USB emulato nel guest, i valori 1 per USB 1.1, 2 per USB 2.0 e 3 per USB 3.0. È disponibile solo con QEMU upstream. A causa delle limitazioni di implementazione questo non è compatibile con i parametri usb e usbdevice . L’impostazione predefinita è (0) nessun controller USB definito.

usbdevice = [“DEVICE”, “DEVICE”, …]

Aggiunge DEVICE al bus USB emulato. Anche il bus USB deve essere abilitato usando usb = 1 . L’uso più comune di questa opzione è usbdevice = [‘tablet’] che aggiunge un dispositivo puntatore utilizzando le coordinate assolute. Tali dispositivi funzionano meglio dei dispositivi di coordinate relative (come un mouse standard) poiché molti metodi di esportazione della grafica guest (come VNC) funzionano meglio in questa modalità. Si noti che questo è indipendente dal dispositivo puntatore effettivo che si sta utilizzando sul lato host / client.

I dispositivi host possono anche essere passati in questo modo, specificando l’host: USBID, dove USBID è del formato xxxx: yyyy. L’USBID può essere in genere trovato usando lsusb (1) o dispositivi usb (1) .

Se si desidera utilizzare il formato “host: bus.addr”, rimuovere qualsiasi “0” iniziale dal bus e addr. Ad esempio, per il dispositivo USB sul bus 008 dev 002, dovresti scrivere “host: 8.2”.

Il modulo usbdevice = DEVICE è anche accettato per la compatibilità all’indietro.

Altre opzioni valide possono essere trovate nella sezione “usbdevice” della documentazione QEMU.

vendor_device = “VENDOR_DEVICE”

Seleziona quale variante del QEMU xen-pvdevice dovrebbe essere usata per questo ospite. I valori validi sono:

nessuna: Lo xen-pvdevice dovrebbe essere omesso. Questo è l’impostazione predefinita.
XenServer: Verrà specificata la variante xenserver di xen-pvdevice (id-dispositivo = C000), che consente l’utilizzo dei driver PV XenServer nel guest.

Questo parametro ha effetto solo quando device_model_version = qemu-xen. Vedi xen-pci-device-reservations (7) per ulteriori informazioni.

PVH Opzioni specifiche per gli ospiti

nestedhvm = BOOLEAN

Questa opzione è disabilitata di default.

bootloader = “PROGRAMMA”

bootloader_args = [“ARG”, “ARG”, …]

timer_mode = “MODE”

Specifica la modalità per i timer virtuali. I valori validi sono i seguenti:

delay_for_missed_ticks: Ritardo per mancate zecche. Non anticipare un tempo di vCPU oltre il tempo di consegna corretto per gli interrupt che sono stati persi a causa della preventiva. Fornire interrupt persi quando la vCPU è riprogrammata e far avanzare gradualmente il tempo virtuale della vCPU per ciascuno.
no_delay_for_missed_ticks: Nessun ritardo per le zecche perse. Come sopra, le interruzioni mancate vengono consegnate, ma il tempo ospite tiene sempre traccia del tempo di wallclock (cioè, reale) mentre lo fa. Questo è l’impostazione predefinita.
no_missed_ticks_pending: Nessun interruzione persa viene sospesa. Invece, per garantire che le zecche siano consegnate ad una velocità diversa da zero, se rileviamo tick mancanti, l’allarme tick interno non viene disabilitato se il vCPU viene preempito durante il successivo periodo di tick.
one_missed_tick_pending: In attesa di un tick spuntato. Gli interrupt persi sono collassati insieme e consegnati come un “ticchettio in ritardo”. L’ora dell’ospite tiene sempre traccia del tempo di wallclock (cioè, reale).

paging

HAP = BOOLEAN: Attiva o disattiva il “paging hardware assistito” (l’uso della funzione della tabella di pagine nidificate nell’hardware). Questa funzione è chiamata EPT (Extended Page Tables) di Intel e NPT (Nested Page Tables) o RVI (Rapid Virtualisation Indexing) di AMD. Se disattivato, Xen eseguirà il guest nella modalità “tabella delle pagine shadow” in cui verranno aggiornati gli aggiornamenti della tabella delle pagine degli ospiti e / o gli svuotamenti di TLB, ecc. L’utilizzo di HAP è l’impostazione predefinita quando disponibile.
oos = BOOLEAN: Attiva o disattiva “offline syncable”. Quando si esegue in modalità tabella pagine shadow, gli aggiornamenti della tabella di pagine del guest potrebbero essere differiti come specificato nei manuali di architettura Intel / AMD. Tuttavia, questo potrebbe esporre bug inaspettati nel guest o trovare bug in Xen, quindi è possibile disabilitare questa funzionalità. L’uso di tabelle di pagine fuori sincrono, quando Xen lo ritiene appropriato, è l’impostazione predefinita.
shadow_memory = MBYTE: Numero di megabyte da riservare per l’ombreggiamento delle pagine pagabili degli ospiti (che agiscono efficacemente come una cache delle pagine tradotte) o da utilizzare per lo stato HAP. Di default questo è 1 MB per guest vCPU più 8 KB per MB di RAM guest. Normalmente non è necessario regolare questo valore. Tuttavia, se non si utilizza il paging con hardware assistito (ovvero se si utilizza la modalità shadow) e il carico di lavoro del guest è costituito da un numero molto elevato di processi simili, l’aumento di questo valore potrebbe migliorare le prestazioni.

Opzioni del modello di dispositivo

Le seguenti opzioni controllano la selezione del modello del dispositivo. Questo è il componente che fornisce l’emulazione dei dispositivi virtuali a un guest HVM. Per un ospite PV, a volte viene utilizzato un modello di dispositivo per fornire back-end per determinati dispositivi PV (di solito un dispositivo framebuffer virtuale).

device_model_version = “DISPOSITIVO-MODELLO”

Seleziona quale variante del modello di dispositivo deve essere utilizzata per questo ospite.

I valori validi sono:

qemu-Xen: Utilizzare il modello di dispositivo unito al progetto QEMU a monte. Questo modello di dispositivo è l’impostazione predefinita per dom0 Linux.
qemu-xen-tradizionale: Usa il modello del dispositivo basato sulla storica forcella Xen di QEMU. Questo modello di dispositivo è ancora il default per NetBSD dom0.

Si consiglia di accettare il valore predefinito per i nuovi ospiti. Se si dispone di guest esistenti, in base alla natura del sistema operativo guest, si potrebbe desiderare di costringerli a utilizzare il modello di dispositivo con il quale sono stati installati.

device_model_override = “PERCORSO”

Sostituire il percorso del file binario da utilizzare come modello del dispositivo. Il binario fornito qui DEVE essere coerente con device_model_version che hai specificato. Normalmente non è necessario specificare questa opzione.

device_model_stubdomain_override = BOOLEAN

Sostituisci l’uso del modello di dispositivo basato su stubdomain. Normalmente questo sarà selezionato automaticamente in base alle altre caratteristiche e opzioni che hai selezionato.

device_model_stubdomain_seclabel = “LABEL”

Assegnare un’etichetta di sicurezza XSM allo stubdomain del modello di dispositivo.

device_model_args = [“ARG”, “ARG”, …]

Passa ulteriori opzioni arbitrarie sulla riga di comando del modello di dispositivo. Ogni elemento nell’elenco viene passato come opzione al modello del dispositivo.

device_model_args_pv = [“ARG”, “ARG”, …]

Passa ulteriori opzioni arbitrarie sulla riga di comando del modello di dispositivo solo per un modello di dispositivo PV. Ogni elemento nell’elenco viene passato come opzione al modello del dispositivo.

device_model_args_hvm = [“ARG”, “ARG”, …]

Passa ulteriori opzioni arbitrarie sulla riga di comando del modello di dispositivo solo per un modello di dispositivo HVM. Ogni elemento nell’elenco viene passato come opzione al modello del dispositivo.

keymaps

Le mappe dei tasti disponibili sono definite dal modello del dispositivo che si sta utilizzando. Comunemente questo include:

        ar  de-ch  es  fo     fr-ca  hu  ja  mk     no  pt-br  sv
        da  en-gb  et  fr     fr-ch  is  lt  nl     pl  ru     th
        de  en-us  fi  fr-be  hr     it  lv  nl-be  pt  sl     tr

L’impostazione predefinita è en-us .

Vedi qemu (1) per ulteriori informazioni.

Opzioni specifiche di architettura

BRACCIO

gic_version = “vN”

Versione del GIC emulata per l’ospite.

Attualmente sono supportate le seguenti versioni:

v2: Emula un GICv2
v3: Emula un GICv3. Si noti che il GIC emulato non supporta la modalità di compatibilità GICv2.
predefinito: Emula la stessa versione dell’hardware GIC nativo utilizzato dall’host in cui è stato creato il dominio.

Ciò richiede la compatibilità hardware con la versione richiesta, in modo nativo o tramite il supporto per la compatibilità con le versioni precedenti dell’hardware.

vuart = “uart”

Per abilitare la console di vuart, l’utente deve specificare la seguente opzione nel file di configurazione di VM:

vuart = “sbsa_uart”

Attualmente, solo il modello “sbsa_uart” è supportato per ARM.

X 86

mca_caps = [“CAP”, “CAP”, …]

(Solo HVM) Abilita le funzionalità MCA oltre a quelle predefinite abilitate dall’hypervisor Xen per il dominio HVM. “CAP” può essere uno nel seguente elenco:

“Lmce”: Intel locale MCE
predefinito: Non sono abilitate funzionalità MCA nell’elenco precedente.

GUARDA ANCHE

xl (1)
xl.conf (5)
xlcpupool.cfg (5)
xl-disk-configurazione (5)
xl-configurazione di rete (5)
xen-tscmode (7)

FILE

/etc/xen/NAME.cfg / var / lib / xen / dump / NAME

RIFERIMENTI

La seguente pagina è basata sulla traduzione della pagina di man: https://xenbits.xen.org/docs/unstable/man/xl.cfg.5.html.

CategoriaManuali

Creare una macchina HVM (Hardware Virtualized) Guest su Xen 4.X

Configurazione dei Dischi Virtuali delle VM Xen

Parametri di Configurazione VM Xen xl.cfg

DESCRIZIONE

SINTASSI

OPZIONI

Argomenti di configurazione obbligatori

Selezione del tipo di dominio guest

Selezione del tipo di ospite deprecato

Opzioni generali

Assegnazione CPU

Programmazione della CPU

Allocazione della memoria

Guest Virtual NUMA Configuration

Azioni per eventi

Direct Kernel Boot

Kernel Boot non diretto

Opzioni ospite PV

Opzioni ospite HVM

Opzioni per gli ospiti PVH

Altre opzioni

dispositivi

Opzioni specifiche per gli ospiti paravirtualizzate (PV)

Opzioni specifiche per gli ospiti completamente virtualizzate (HVM)

Dispositivo di avvio

Tipo di controller del disco emulato

paging

Funzionalità del processore e della piattaforma

Guest Virtual Time Controls

Layout di memoria

Supporto per la paravirtualizzazione degli ospiti HVM

Dispositivo grafico VGA emulato

Spice Graphics Support

Hardware emulato vario

PVH Opzioni specifiche per gli ospiti

paging

Opzioni del modello di dispositivo

keymaps

Opzioni specifiche di architettura

BRACCIO

X 86

GUARDA ANCHE

FILE

RIFERIMENTI

Lascia un commento Annulla risposta