virtual machine manager e qemu (ponce)

[tornadomig]

ciao a tutti!!!

avrei una domanda per ponce, ma se qualcun'altro mi sa erudire oltre all'interessato, va benissimo lo stesso.

ho clonato il repo di ponce (pimpmyslack) della slack64-current e devo dire, ritengo sia davvero comodo installare tutti quei bei pacchettini. per questo sempre grazie, caro ponce.

tra questi vi compare virtual machine manager e qemu, che volevo testare per capirci qualcosa. morale della favola, non capisco come creare una qualsiasi virtual machine. la gui non vede qemu.

dove potrebbe essere il mio inghippo?

grazie a voi tutti!

[ponce]

libvirt cerca qemu-kvm nel path e dovresti averlo come link simbolico a qemu-system-x86_64 (il link e' generato durante l'installazione del pacchetto qemu).

non e' che per caso non hai avviato il demone di libvirt (/etc/rc.d/rc.libvirt)?

eventualmente copia e incolla l'errore che ti da.

[tornadomig]

ecco qua

impossibile connettersi a libvirt.

internal error: Cannot find suitable emulator for x86_64

Libvirt URI is: qemu:///system

Traceback (most recent call last):
File "/usr/share/virt-manager/virtManager/connection.py", line 935, in _open_thread
self._populate_initial_state()
File "/usr/share/virt-manager/virtManager/connection.py", line 897, in _populate_initial_state
logging.debug("conn version=%s", self._backend.conn_version())
File "/usr/share/virt-manager/virtinst/connection.py", line 327, in conn_version
self._conn_version = self._libvirtconn.getVersion()
File "/usr/lib64/python2.7/site-packages/libvirt.py", line 3881, in getVersion
if ret == -1: raise libvirtError ('virConnectGetVersion() failed', conn=self)
libvirtError: internal error: Cannot find suitable emulator for x86_64

il demone parte
# nano /etc/rc.d/rc.local

if [ -x /etc/rc.d/rc.libvirt ]; then
/etc/rc.d/rc.libvirt start
fi

[ponce]

prima di tutto controlla di avere le estensioni per usare kvm abilitate nel BIOS.

dopo che sei sicuro di averle abilitate, se lanci qemu cosi' che output hai nella console da cui l'hai lanciato?

Codice: Seleziona tutto

qemu-system-x86_64 -enable-kvm -cpu host

cosa restituiscono i seguenti comandi (da root)?

Codice: Seleziona tutto

virsh list --all
ls -la /usr/bin/qemu-kvm

e' un'installazione pulita e completa di slackware64-current?

[tornadomig]

qualcosa salta fuori

$ qemu-system-x86_64 -enable-kvm -cpu host
qemu-system-x86_64: error while loading shared libraries: libGLESv2.so.2: wrong ELF class: ELFCLASS32

# virsh list --all
Id Nome Stato
----------------------------------------------------

ls -la /usr/bin/qemu-kvm
lrwxrwxrwx 1 root root 18 set 21 23:40 /usr/bin/qemu-kvm -> qemu-system-x86_64*

questa current-64 l'ho installata senza kde di pat. ho aggiunto poi i pacchetti di kde 5 di alienbob. certamente, multilib e con nvidia come driver video

[ponce]

sembra che tu abbia installato una libreria a 32bit invece di quella a 64bit e dovrebbe essere nel pacchetto mesa: disinstalla il driver nvidia, verifica (eventualmente reinstallali) di avere installato mesa-*-x86_64 e mesa-compat32-*-x86_64 (non mesa-*-i586) e reinstalla il driver nvidia.

ho due ipotesi (magari sbagliate entrambe, boh?):
- hai installato i driver nvidia dal file NVIDIA*run invece che dagli script di SBo? usa questi ultimi, correggono anche dei bug nel linking delle librerie che ha l'installer nvidia;
- hai aggiornato/installato slackware64-current intorno al 21 agosto e non hai piu' aggiornato il pacchetto mesa (non so gli altri): quel giorno in 64-current era finito per sbaglio un pacchetto a 32bit, sistemato poco dopo.

perdonami se apro una piccola parentesi: se non hai installato il kde che e' fornito con slackware e' possibile che altre cose non ti funzionino.
a prescindere da questo problema specifico con qemu (che credo proprio dipenda dal tuo setup, vediamo se ne veniamo a capo), tieni di conto che quelli che stai usando sono i pacchetti che faccio per le mie installazioni complete di slackware64-current e sono a disposizione per chi se li vuole scaricare cosi' come sono per questa piattaforma: in generale non ce la faccio a dare un supporto per l'utilizzo (per ragioni di tempo), a maggior ragione se mescolati con pacchetti di altri repository di terze parti (ci diventerei matto).
e' per questo che ho messo un README (a cui oggi ho aggiunto una riga)

Codice: Seleziona tutto

personal packages repository for slackware64-current
----------------------------------------------------

this is my personal repository for slackware64-current: these are the
packages I use on my own installations.
you are free to use this stuff but there are no guarantees they
will work for you (in particular if used with packages from other
third party repositories), nor I take any responsibility if your cat
is harmed during their use. :)

you can check for dependencies on slackbuilds.org if you need single
packages (optional dependencies might be also required), but
all you need besides a current full default installation should
be already in this folders (HINT: install a full set ;) )

(latest global rebuild september 8th 2015)

[tornadomig]

# ls /var/log/packages/|grep mesa
mesa-11.0.0-x86_64-1
mesa-compat32-11.0.0-x86_64-1compat32

mesa mi sembra a posto.
piuttosto mi hai fatto ricordare che qualche mese fa, presa la decisione di mettere kde 5, mi scaricai la current64 con rsync ma escludendo kde e kdei. tenni xfce che uso tuttora. poi dopo aver reso multilib la slack current64 usai sbopkg per nvidia-kernel e poi nvidia-driver. ma con sbopkg, nvidia-driver non voleva saperne di compilare. e allora gli ficcai NVIDIA*run nudo e crudo per rabbia. poi lo disinstallai e riutilizzai gli slackbuilds alla vecchia maniera e da allora nvidia-driver lo metto in questa maniera. e funziona. che poi sono solito fare cosi ma mi erano girate le...
adesso sono con i nouveau. comunque continua a darmi quell'errore se provo a dare il comando

$ qemu-system-x86_64 -enable-kvm -cpu host
qemu-system-x86_64: error while loading shared libraries: libGLESv2.so.2: wrong ELF class: ELFCLASS32

[ponce]

disinstalla il driver nvidia, verifica (eventualmente reinstallali) di avere installato mesa-*-x86_64 e mesa-compat32-*-x86_64 (non mesa-*-i586) e reinstalla il driver nvidia.

prova a fare questa operazione.

- esci da X;
- prima dai il comando

Codice: Seleziona tutto

nvidia-switch --remove

(da dare sempre prima di rimuovere il pacchetto nvidia-driver quando installato da SBo);
- poi

Codice: Seleziona tutto

removepkg nvidia-driver mesa mesa-compat32

- installa mesa dal repository ufficiale e mesa-compat32 da quello per current di Alien Bob;
- reinstalla nvidia-driver dallo SlackBuild rigenerando il pacchetto dagli script che sono su SBo non, eventualmente, da una tua vecchia copia locale dove magari hai cambiato solo la versione, mi raccomando.
quando lo lanci ricordati di passargli il parametro COMPAT32=yes, visto che sei su un sistema multilib.

poi, una volta che sei tornato su X, postami per favore l'output dei comandi (da root)

Codice: Seleziona tutto

ldd /usr/bin/qemu-system-x86_64 | grep GLES
updatedb
locate libGLESv2.so.2

[tornadomig]

ok reinstallato tutto come da tue indicazioni, grazie!

# ldd /usr/bin/qemu-system-x86_64 | grep GLES
libGLESv2.so.2 => not found

dato updatedb

# locate libGLESv2.so.2
/usr/lib/libGLESv2.so.2.0.0
/usr/lib/libGLESv2.so.2
/usr/lib64/libGLESv2.so.2.0.0
/usr/lib64/libGLESv2.so.2

[ponce]

sulla mia macchina

Codice: Seleziona tutto

# ldd /usr/bin/qemu-system-x86_64 | grep GLES
        libGLESv2.so.2 => /usr/lib64/libGLESv2.so.2 (0x00007fd2e4969000)
# cat /etc/ld.so.conf 
/lib64
/usr/lib64
/usr/local/lib64
/usr/x86_64-slackware-linux/lib64
/usr/lib64/seamonkey
# file /usr/lib64/libGLESv2.so.2.0.0
/usr/lib64/libGLESv2.so.2.0.0: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped
# ls -1 /var/log/packages/*-i?86-*
#

che dicono gli altri tre comandi sulla tua?

[tornadomig]

ecco qua!

# cat /etc/ld.so.conf
/lib64
/usr/lib64
/usr/local/lib64
/usr/x86_64-slackware-linux/lib64
/usr/lib64/seamonkey

file /usr/lib64/libGLESv2.so.2.0.0
/usr/lib64/libGLESv2.so.2.0.0: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped

ls -1 /var/log/packages/*-i?86-*
/var/log/packages/flashplayer-plugin-11.2.202.521-i386-1alien
/var/log/packages/steamclient-1.0.0.50-i386-1alien

guarda, ho capito che il sistema, a causa dell'installazione di NVIDIA*run, non e' come dovrebbe essere. davvero, ringrazio tanto della pazienza e aiuto. mi rimetto al lavoro e rimetto pulita la current64

[ponce]

non so se sia stato quello comunque non mi viene a mente altro...

gia' che ci sei, prima di installare i pacchetti dal mio repository lancia questo script che ti crea gli utenti e i gruppi necessari

Codice: Seleziona tutto

groupadd -g 210 clamav
useradd -u 210 -d /dev/null -s /bin/false -g clamav clamav
groupadd -g 220 tor
useradd -u 220 -g 220 -c "The Onion Router" -d /dev/null -s /bin/false tor
groupadd -g 206 privoxy
useradd -u 206 -g 206 -c "Web Proxy" -d /dev/null -s /bin/false privoxy
groupadd -g 208 lighttpd
useradd -u 208 -g lighttpd -d /var/www lighttpd

[tornadomig]

ciao!
ho delle news. ho rimosso il tuo pacchetto di qemu e tramite gui di sbopkg ho compilato (a me ha richiesto + di 2 GB di ram in /tmp) qemu 2.3.0 e risulta strano perche' su slackbuilds.org vi si scarica la versione 2.4.0. comunque ora ho installato con successo qemu e anche aqemu per provare. funziona tutto. anche virtualbox compilato tra l'altro. e non mi da' piu' errore all'apertura di virtual machine manager del tuo repo.
mi rimane da capire come mai in /usr/lib64 vi siano quelle due librerie...
nei vari log durante il boot compare questo

/sbin/ldconfig libraries libGLESv2.so.2.0.0 and libGLESv2.so.352.30 in directory /usr/lib64 have same soname but different type .

[tornadomig]

uffah non e' come credevo, adesso che provo a creare le vm non va...io mollo e rimetto tutto con santa pazienza e rassegnazione. grazie caro ponce!!!

[ponce]

adesso che provo a creare le vm non va

forse non e' determinante, pero' puoi provare a mettere questo parametro dentro /etc/libvirt/qemu.conf

Codice: Seleziona tutto

user = "tuo_utente"

dove tuo_utente e' l'utente che usa il desktop da cui hai lanciato virt-manager (il tuo utente, insomma) e riavviare il demone di libvirt.

comunque quando qualcosa non va, come in questo caso ma vale anche come principio generale, potrebbe essere utile incollare almeno l'errore senno' capire quale sia il problema diventa ancora piu' difficile.