Vsphere4: i sistemi guest riportano un uso esagerato della RAM

E possibile che vcenter server segnali un esagerato (e tuttaltro che reale) consumo di RAM da parte dei sistemi guest basati su Windows.

C'e' una patch per host esx basati su CPU Intel Nehalem ma anche un workaround che consiste nel disabilitare il large page support.

Per disabilitare il large page support per l'intero host ESX, seguite le istruzioni seguenti e usando il client di VMware:

1 Nel pannello sinistro di VI Client, scegliere l'host ESX.
2 Nel pannello destro di VI Client, clicare sulla scheda Configuration.
3 Scegliere Software > Advanced Settings. Si apre la dialog box Advanced Settings.
4 Nel pannello sinistro della dialog box Advanced Settings, Scegliere Mem.
5 Nel pannello destro della dialog box Advanced Settings, settare Mem.AllocGuestLargePage a 0 (zero).
6 Cliccare OK per chiudere la dialog box Advanced Settings.

Per disabilitare il large page support del sistema operativo di una macchina virtuale, aggiungere la linea seguente nel file di configurazione della macchina virtuale:

monitor_control.disable_mmu_largepages = TRUE

ESXi 4: importare una virtual machine da VMware server 2.0

Dopo aver copiato la directory relativa alla virtual machine da trasferire nel datastore dell'infrastruttura vsphere e aver aggiunto la virtual machine all'inventory, al momento di avviarla otteniamo un errore del tipo:

Failed to open disk scsi0:0: Unsupported and/or invalid disk type 7. Did you forget to import the disk first? Unable to create virtual SCSI device for scsi0:0, '/vmfs/volumes/xxxxxxx/gwrkvm5.2.1ce/gwce5.2.1.vmdk

Per sistemare la cosa occorre clonare il disco virtuale modificando il tipo in "thin provisioning" con il comando:

vmkfstools -i source.vmdk destination.vmdk -d thin

e modificare i settaggi della macchina virtuale per utilizzare destination.vmdk al posto di source.vmdk

VMware ESX: Impostare la password di root

Per cambiare la password dell'utente root, dovete eseguire un reboot del vostro server ESX e accedervi in single user mode alla console di servizio. Ecco come:

ESX Server 3.x/4.x:

1. Reboot
2. Quando appare la schermata di GRUB, premere la barra spaziatrice per interrompere il boot automatico.
3. Usare i tasti freccia per selezionare Service Console only (troubleshooting mode).
4. Premere il tasto "a" per modificare gli argomenti del kernel (boot options).
5. Sulla linea presentata, digitare uno spazio seguito dalla parola "single".
6. Premere il tasto "Enter". Il server eseguira' un boot in single user mode.
7. Quando apparira' il prompt della shell (ad esempio: sh-2.05b#), digitate il comando "passwd" e premete il tasto "Enter".
8. Seguite le istruzioni visualizzate per settare una nuova password per l'utente root.
9. Una volta settata la password correttamente, riavviare il server con il comando "reboot" per consentire le normali attivita' del server ESX.

ESX Server 2.x:

1. Reboot.
2. Quando appare la schermata di LILO, premere la barra spaziatrice per interrompere il boot automatico.
3. Al prompt di LILO, digitare "linux -s"
4. Premere il tasto "Enter". Il server eseguira' un boot in single user mode.
5. Quando apparira' il prompt della shell (ad esempio: sh-2.05b#), digitate il comando "passwd" e premete il tasto "Enter".
6. Seguite le istruzioni visualizzate per settare una nuova password per l'utente root.
7. Una volta settata la password correttamente, riavviare il server con il comando "reboot" per consentire le normali attivita' del server ESX.

Virtualbox: usa troppa CPU? Decapitatelo!!!!

Mi servivano due macchine virtuali debian per fare degli esperimenti.
Il "serverino" con la nuova memoria sembrava adatto ad ospitarle.
Peccato che dopo aver installato virtualbox-ose e le due macchine virtuali non rimanessero risorse sufficienti a far girare il tutto.

Ogni macchina virtuale, in stato di idle, si portava via il 30-35% di CPU, se poi una delle macchine cominciava a fare qualcosa si passava a un bel 99.4%

Diciamo che il serverino ne soffriva (oltre al caldo terribile e all'insidia delle api morte)

La soluzione e' virtualbox-puel (ovvero la versione non-open di virtualbox che non viene pubblicata sui repository ma e' scaricabile dal sito SUN/Virtualbox).

Trovate i pacchetti binari per le piu' diverse piattaforme.

Due aspetti positivi della versione PUEL non presenti sulla OSE:
1) utilizzo delle periferiche USB (ma in questo caso non era importante)
2) possibilita' di eseguire una virtual machine senza visualizzarla nella console di virtualbox

Questo consente alle macchine virtuali di girare indisturbate senza scomodare X per la visualizzazione (tantopiu' che sul server X non dovrebbe nemmeno starci ;-) e consumare risorse preziose.

I processi VboxHeadless (da qui la decapitazione del titolo) infatti utilizzeranno una percentuale irrisoria di CPU quando le VM sono in idle. La percentuale aumenta con il risvegliarsi delle VM ma torna subito a calare quando queste tornano in idle.

Per accedere alle virtual machine si utilizza un qualsiasi client RDP (rdesktop su Linux, Remote Desktop su Windows)

Per lanciare la virtual machine si usa il comando:

VBoxVRDP --startvm NOME_VIRTUAL_MACHINE -p NUMERO_PORTA_PER_RDP &

Per default, la porta assegnata per l'RDP e' 3389, le virtual machine successive alla prima devono essere assegnate ad altri numeri di porta per consentirne l'accesso.

VBoxVRDP --startvm VM1 &
VBoxVRDP --startvm VM2 -p 3390 &

Per accedere alle macchine virtuali dal vostro client vi bastera' lanciare i seguenti comandi:

rdesktop IP_ADDRESS_SERVER:3389
rdesktop IP_ADDRESS_SERVER:3390

Per inviare un comando di arresto (shutdown) alle macchine virtuali vi bastera' lanciare il seguente comando:

VBoxManage controlvm NOME_VIRTUAL_MACHINE acpipowerbutton

Quindi per arrestare le due VM dell'esempio precedente:

VBoxManage controlvm VM1 acpipowerbutton
VBoxManage controlvm VM2 acpipowerbutton

Vmware: la macchina virtuale non esegue il boot da cd

Il problema non si pone a macchina vergine, quando bisogna installare il sistema operativo.

Purtroppo a installazione avvenuta potreste avere ancora bisogno di bootare da cd (ad esempio per eseguire gparted sulla partizione di root per estenderla dopo aver ingrandito il disco virtuale da console)

Il problema e' che il bios delle macchine virtuali e' impostato in modo tale che l'hard disk ha priorita' maggiore rispetto al cd.
Ulteriore problema: il boot della macchina virtuale e' talmente rapido che non riuscite a premere F2 per accedere al setup del bios e modificare questa priorita'.

La soluzione e' tutta "artigianale", insomma dovete modificare a manona un file di configurazione, in particolare, ammettendo ad esempio che la macchina virtuale si chiami linux, il file linux.vmx.

Aggiungete in fondo al file una riga seguendo questa sintassi:

bios.bootDelay = "ritardo_in_millisecondi"

Ad esempio:

bios.bootDelay = "15000"

impostera' un ritardo di 15 secondi durante il quale potrete premere F2, accedere al setup del bios e impostare il cd come prima periferica di boot.