virt-manager e rete virtuale

[joe]

Ciao a tutti, ho installato qemu libvirt virt-manager via SBo usando sbopkg e relativa coda di pacchetti.

Dunque, ancora sulla 14.2 avevo un alias per "accendere" libvirt, da utente semplice attraverso sudo:

Codice: Seleziona tutto

sudo /etc/rc.d/rc.libvirt start

Lanciando il comando sopra non compaiono errori.

A quel punto apro virt-manager, creo una nuova macchina virtuale, ma se tento di avviarla mi dice (vado a memoria) che non riesce a gestire la rete virtuale (default) perché non trova nel mio PATH l'eseguibile "dnsmasq".
Il ché è vero in effetti:

Codice: Seleziona tutto

# which dnsmasq
/usr/sbin/dnsmasq

Ovvero cercando dnsmasq come root eco che appare in "/usr/sbin", una dir che no fa parte, volutamente, dell'utente semplice con cui avvio virt-manager.
Nella 14.2 però non avevo problemi, e se ben ricordo il PATH dell'utente semplice era sempre quello, così limitato.

Ho il sospetto di non aver seguito bene qualche README presente su SBo.
Dove può stare il problema? E quale soluzione migliore per risolverlo?

Perché potrei anche aggiungere al PATH dell'utente semplice /usr/sbin, ma non mi pare la scelta migliore.

[joe]

Riguardando il README di qemu leggo:

Codice: Seleziona tutto

libslirp (user mode networking), libcacard, spice, usbredir,
virglrenderer, libnfs, snappy, device-tree-compiler, glusterfs, and vde2
are optional dependencies.

To enable user mode networking, install libslirp (availale on SBO), then
compile qemu:

SLIRP=yes ./qemu.SlackBuild

Forse l'inghippo è quello... non sono sicuro e ricompilare, va be' si può fare ma non è una cosa rapidissima.
Se avete conferme o suggerimenti dite pure...

[ponce]

Ciao a tutti, ho installato qemu libvirt virt-manager via SBo usando sbopkg e relativa coda di pacchetti.

Dunque, ancora sulla 14.2 avevo un alias per "accendere" libvirt, da utente semplice attraverso sudo:

Codice: Seleziona tutto

sudo /etc/rc.d/rc.libvirt start

Lanciando il comando sopra non compaiono errori.

A quel punto apro virt-manager, creo una nuova macchina virtuale, ma se tento di avviarla mi dice (vado a memoria) che non riesce a gestire la rete virtuale (default) perché non trova nel mio PATH l'eseguibile "dnsmasq".
Il ché è vero in effetti:

Codice: Seleziona tutto

# which dnsmasq
/usr/sbin/dnsmasq

Ovvero cercando dnsmasq come root eco che appare in "/usr/sbin", una dir che no fa parte, volutamente, dell'utente semplice con cui avvio virt-manager.
Nella 14.2 però non avevo problemi, e se ben ricordo il PATH dell'utente semplice era sempre quello, così limitato.

Ho il sospetto di non aver seguito bene qualche README presente su SBo.
Dove può stare il problema? E quale soluzione migliore per risolverlo?

Perché potrei anche aggiungere al PATH dell'utente semplice /usr/sbin, ma non mi pare la scelta migliore.

e' perche' stai usando sudo (${parolaccia_a_piacere}), che ti fa usare la variabile d'ambiente $PATH del tuo utente: apri una shell di root con "su -" o, in alternativa, usa la variabile secure_path in /etc/sudoers

Codice: Seleziona tutto

 ## Uncomment to use a hard-coded PATH instead of the user's to find commands
# Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

[joe]

Prendiamola a monte.
Quale sarebbe il modo "giusto" di utilizzare libvirt e virt-manager?

Io lancio libvirt con sudo, andrebbe lanciato come root in teoria, ma non voglio che parta automaticamente all'avvio del sistema, mi serve raramente.
Lo lanciavo così anche su slack14.2, l'alias è lo stesso, e problemi di dnsmasq non trovato nel PATH non ne avevo avuti.

Poi lancio virt-manager come utente semplice.
Provo a modificare sudoers e mettere il PATH rigido, ma mi sa che possa impedire a qualcos'altro che usa sudo di funzionare correttamente se sono coinvolti eseguibili dell'utente semplice.
Va be' proviamo così. Anzi prima faccio la prova di avvio del servizio libvirt da root diretto. E vediamo se funge...

[joe]

Fatta prova come dicevi tu: avvio di libvirt da root senza sudo.

Così funziona.
Ho aggiunto la scheda di rete alla macchina virtuale e non ha battuto ciglio. Quindi il problema sembra quello...

Però...
ho notato che in /etc/rc.d c'è un rc.libvirt.new...
Uhmmm...
Vedo che contiene la variabile $VIRSH impostata a /usr/bin/virsh anziché il percorso all'eseguibile, che invece nel vecchio rc.libvirt ancora in uso c'è ed è /usr/sbin/virsh.

Aspetta un attimo... ma allora come caspita fa a funzionare non si sa. Altro che sudo.

Codice: Seleziona tutto

# ls /usr/sbin/virsh
/bin/ls: impossibile accedere a '/usr/sbin/virsh': File o directory non esistente

# which virsh
/usr/bin/virsh

# grep VIRSH= /etc/rc.d/rc.libvirt.new
VIRSH=/usr/bin/virsh

# grep virsh /etc/rc.d/rc.libvirt
  for machine in $(/usr/sbin/virsh list --name --state-running | grep -v ^$) ; do
    /usr/sbin/virsh reboot $machine
  for machine in $(/usr/sbin/virsh list --name --state-running | grep -v ^$) ; do
    /usr/sbin/virsh shutdown $machine &
  while [ $(/usr/sbin/virsh list --name --state-running | grep -v ^$ | wc -l) -gt "0" ]; do
  if [ $(/usr/sbin/virsh list --name --state-running | grep -v ^$ | wc -l) -gt "0" ];then
    for machine in $(/usr/sbin/virsh list --name --state-running | grep -v ^$) ; do
      /usr/sbin/virsh destroy $machine
  for machine in $(/usr/sbin/virsh list --name | grep -v ^$) ; do
    /usr/sbin/virsh managedsave $machine &
  while [ $(/usr/sbin/virsh list --name | grep -v ^$ | wc -l) -gt "0" ]; do
  if [ $(/usr/sbin/virsh list --name | grep -v ^$ | wc -l) -gt "0" ];then
    for machine in $(/usr/sbin/virsh list --name | grep -v ^$) ; do
      /usr/sbin/virsh destroy $machine
  for network in $(/usr/sbin/virsh net-list --name); do
    /usr/sbin/virsh net-destroy "$network"

Niente allora prima di tutto butto via il vecchio rc.libvirt e riprovo con sudo.

Non mi spiego come faccia a funzionare, anche da root l'avvio del servizio usa il vecchio rc.libvirt che contiene /usr/sbin/virsh, ma quell'eseguibile non esiste nella slackware 15!
Misteri, si vede che anche senza l'eseguibile virsh, il servizio riesce a fare qualcosa. Boh.

Se avete lumi illuminate.
Aggiorno subito

[ponce]

penso che sia perche' virsh viene chiamato solo in alcuni casi in rc.libvirt, principalmente per lo spegnimento/riavvio/salvataggio di stato dei guest e di libvirtd stesso, non e' chiamato per l'avvio del demone: per questa ragione, anche se e' cambiato il suo percorso, quando fai "/etc/rc.d/rc.libvirt start" funziona lo stesso anche col vecchio rc.libvirt.

[joe]

Ad ogni modo ho buttato il vecchio e messo il nuovo.

Prova 1 - Avvio da root diretto del servizio rc.libvirt start
- posso aggiungere scheda di rete senza errori, almeno il tipo "e1000e", mentre virtio non da' errori ma poi non la vede perché c'era un assaggio in più per installare quei driver anche lato host se non ricordo male... cosa che non ho fatto.

Prova 2 - Avvio da user con sudo
- stesso errore di prima:

Codice: Seleziona tutto

Unable to find 'dnsmasq' binary in $PATH: File o directory non esistente

Quindi il problema sembrerebbe proprio sudo.

[joe]

OK ho sbloccato come dicevi il secure_path in /etc/sudoers:

Codice: Seleziona tutto

Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

Riprovando ad avviare libvirt con l'alias da utente semplice e ad aggiungere in virt-manager una scheda di rete alla macchina virtuale, ora sembra non dare errori.

PS.
non so se vi sia una via più pulita...
Io vorrei avviare libvirt alla bisogna e farlo senza dovermi loggare come root. Ora digito "virton" e poi lancio virt-manager da interfaccia grafica. Però virton è l'alias basato su sudo. Se avete alternative papabili dite pure.

Niente, grazie mille del suggerimento!