VMware server: pagina bianca su accesso web

Problema:

cercando di accedere all'interfaccia web di VMware server (https://NOMESERVER:8333) si ottiene una pagina bianca o viene ripetuta la richiesta di accettazione del certificato.

Soluzione:

Caricare la pagina da una nuova istanza del browser

VMware server 2.0.1 64bit per sistemi linux amd64

Ho installato Debian Lenny 64bit e volevo farci girare VMware server.
Ho letto diversi documenti che consentivano di eseguire senza problemi VMware server 2 a 32 bit su una macchina a 64 bit, ma durante un giretto sul sito www.vmware.com ho scoperto che la versione 2.0.1 e' stata rilasciata anche a 64 bit.

L'installazione si svolge come per le versioni precedenti:

Si scarica il file VMware-server-2.0.1-156745.x86_64.tar.gz
tar xzvf VMware-server-2.0.1-156745.x86_64.tar.gz
cd vmware-server-distrib
apt-get install build-essential
apt-get install linux-headers-$(uname -r)
export CC=gcc-4.1
./vmware-install.pl

VMware: A corto di spazio su una macchina ESXi?

PROBLEMA:

Macchina virtuale si blocca e appare il seguente errore:
Virtual Machine Message

msg.hbacommon.outofspace: There is no more space for the redo log of VMNAME_1-000001.vmdk. You may be able to continue the session by freeing disk space on the relevant partition, and clicking Retry. Otherwise click Abrot to terminate this session.

Apparentemente pero' c'e' nessun disco del sistema sembra avere problemi di capienza.

In precedenza c'era uno snapshot, ma e' stato eliminato: per verificare basta verificare sullo snapshot manager del VI client.

L'errore sembra comunque fare riferimento al redo log tipico di uno snapshot.

SOLUZIONE:

Il problema e' dato proprio da quello snapshot che pur essendo stato cancellato esiste ancora. ESXi ha un bug per cui quando cancelli uno snapshot le modifiche vengono riportate nel file originale.

Quando il file diventa troppo grande, le modifiche non vengono riportate correttamente (quando non vengono riportate per niente) ma il link allo snapshot nello snapshot manager viene rimosso (come nel caso descritto)

Il file continua a crescere in quanto costituito dalle modifiche differenziali dell'originale.

Una soluzione per risolvere questo problema e' convertire la VM che da' problemi in un'altra immagine mediante VMware Convert. Con ESX sarebbe stato possibile da linea di comando, in ESXi non e' possibile e quindi quella proposta e' l'unica soluzione.

Se si aspetta troppo il file potrebbe crescere a tal punto da riempire il disco e impedire il boot a qualsiasi immagine che vi sia installata.

Nuove soluzioni per la virtualizzazione targate Red Hat

Red Hat comincia la fase beta dei suoi nuovi prodotti per virtualizzazione.
L'hypervisor KVM (Kernel-based Virtual Machine), per ora, non si sostituira' alle soluzioni Xen attualmente supportate da Red Hat, ma vedremo quali saranno in futuro le politiche aziendali in tal senso.

Il vantaggio di KVM su Xen sarebbe dato dallo stretto contatto del primo con lo sviluppo del kernel di Linux.

error: asm/semaphore.h: No such file or directory

Compilando i moduli di virtualbox per il nuovo kernel 2.6.27-9 ricevevo l'errore citato nel titolo del post.

Dovete trovare nei sorgenti che state compilando la riga

#include 

E sostituirla con queste linee di codice:

#if (LINUX_VERSION_CODE < KERNEL_VERSION(2,6,19))   
  #include 
#else
  #include 
#endif

Per quanto riguarda i moduli di virtualbox la soluzione e' stata piu' semplice: sono passato dalla versione 1.6.2-gutsy alla 2.0.6-intrepid :)

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

Virtualbox: supporto periferiche USB

Ci sono due versioni di Virtualbox:

1. OSE
2. PUEL

La versione OSE e' quella liberamente installabile dai repository, e' completamente free e non consente l'uso di periferiche USB.

La versione PUEL non e' free, pero' e' liberamente scaricabile dal sito del produttore: consente l'uso di periferiche USB.
Peccato che dopo averla installata voi vediate che Virtualbox rileva le periferiche USB collegate al vostro computer....ma non le rende disponibili alle virtual machine e voi le vedete listate in quel grigino spento degli item non selezionabili.

Ecco la soluzione:

-Create un gruppo chiamato "usbfs" e aggiungete il vostro utente (quello che esegue normalmente Virtualbox) ad esso.

-Lanciate il seguente comando:

sudo gedit /etc/fstab

-Copiate le linee seguenti in questo file, facendo attenzione a cambiare l'ID di gruppo con quello assegnato al gruppo usbfs dal vostro sistema.

# in questo esempio 1001 e' l'ID del gruppo usbfs
none /proc/bus/usb usbfs devgid=1001,devmode=664 0 0

-Salvate e chiudete il file.


-Lanciate il seguente comando:

VBoxManage list usbhost

-Usate l'output di questo comando per configurare i filtri (li vedremo in seguito in un nuovo post) USB in Virtualbox.

-Eseguite un reboot

ATTENZIONE!!!

Le periferiche USB devono essere smontate prima che la virtual machine le possa riconoscere!!!

AGGIORNAMENTO!!!

Se non smontate un drive esterno prima di eseguire il boot della virtual machine, questa acquisira' la precedenza sulla periferica e ne eseguira' l'unmounting dal vostro sistema operativo principale. Se la virtual machine e' gia' in esecuzione bastera' scollegare e subito ricolegare la periferica USB per renderla disponibile alla virtual machine.

AGGIORNAMENTO 2!!!

Non e' necessario (almeno sui sistemi Ubuntu) creare il gruppo usbfs. Si puo' usare infatti il gruppo plugdev che e' gia' dedicato ad occuparsi delle periferiche rimovibili ed e' gia' associato al vostro utente principale in fase di installazione.

Si tratta quindi di impostare la linea che abbiamo aggiunto prima al file /etc/fstab in questo modo:

none /proc/bus/usb usbfs devgid=46,devmode=664 0 0

Virtualbox: Unknown error creating VM (VERR_HOSTIF_INIT_FAILED)

Questo errore puo' capitare in caso utilizzate Virtualbox con interfacce di rete virtuali in bridge con le interfacce fisiche della macchina.

Soluzione brutta:

sudo chmod 666 /dev/net/tun

LA Soluzione:

Controllate che il vostro utente faccia parte del gruppo vboxusers

Se per caso l'errore fosse ancora li' dopo questa verifica, probabilmente e' necessario ristabilire le corrette permission sul device. Lanciate senza timore (oddio ;-) il seguente comando:

sudo chown :vboxusers /dev/net/tun

Virtualbox: migrazione di guest windows ... schermata blu

Spostando una macchina virtuale (windows xp o 2003) da un server all'altro, si puo' ottenere un orrenda schermata blu (BSOD) che le impedisce di partire correttamente.

Soluzione:
Abilitare IO-APIC nei settaggi della macchina virtuale
Invertire il settaggio General -> Advanced -> IDE Controller Type (puo' essere PIIX3 o PIIX4)

Virtualbox: gli snapshot, questi sconosciuti.....

Ecco un'ottima guida per scoprire (o ripassare) il funzionamento degli snapshot in Virtualbox:

Parte 1
Parte 2

(Fonte giornaledisistema.blogspot.com)

Virtualbox: montare gli shared folder da guest linux

mount - t vboxfs [shared folder name] [mount point]

nel post originale c'erano 2 commenti:

marco ha detto...

e se volessi modificare l'fstab del pc host, senza dover rimontare ogni volta manualmente?


Francesco Conti ha detto...

al limite puoi cambiare l'fstab del guest (e non dell'host)

suppongo che vada bene scrivere

[shared folder name] [mount point] vboxfs defaults 0 1

(ovviamente tutto da provare :-)

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.

VMware server: la macchina virtuale non vede periferiche usb???

Verificare se nella definizione della macchina virtuale e' compreso il controller USB. In caso contrario aggiungerlo dall'apposita funzione della console di manutenzione.

Selezionando la macchina virtuale dovrebbe esserci un pulsante relativo al sistema USB:


Piu' in dettaglio:


Cliccandolo dovrebbe apparire un menu:


su cui selezionare le periferiche USB da associare alla macchina virtuale corrente.
Ora la macchina virtuale dovrebbe essere in grado di utilizzare le perferiche selezionate.

VMware server remote console: problemi con tastiera

Uno scomodo problema se usate la console remota di VMware server 2.0. Si tratta di un plugin per firefox che vi permette di accedere alle console delle virtual machine.

In pratica alcuni tasti, e soprattutto le frecce, non funzionano su certe combinazioni di firefox/sistema operativo.

Nel mio caso Firefox 3 / Ubuntu 8.10. Me n'ero accorto installando una VM con debian, non mi era possibile muovere con le frecce il cursore per selezionare tastiera, localizzazione, timezone, ecc ecc.

Ho installato Ubuntu 8.04 in un'altra partizione del mio portatile e il problema non si presentava, aggiornando il sistema alla 8.10 si tornava nel delirio precedente :(

Per fortuna una soluzione c'e', bisogna inserire questa riga nel file ~/.vmware/config (/etc/vmware/config se volete correggere il problema per tutti gli utenti del sistema):

xkeymap.nokeycodeMap = true