slacky.eu

Dunque cerco di essere breve, in rete si trova una marea di roba ma al momento non ho afferrato la soluzione al problema.

Ad ogni modo su slack 15.0 ho una macchina virtuale con windows 7 che dispone di una scheda di rete virtuale, quella di default che viene assegnata da virt-manager.
Il sistema guest comunica con l'host attraverso il device vbr0 (virtual bridge se non sbaglio) che viene tirato in piedi quando si avvia libvirt.

Utilizzo il tutto:
- facendo partire libvirt con /etc/rc.d/rc.libvirt start
- poi apro virt-manager e faccio partire la macchina virtuale

Il problema è che salta fuori un errore relativo la scheda di rete "default" che non risulta attiva. Invece non toccando nulla dovrebbe esserlo proprio di default credo.
Verificando con "virsh net-list --all", la rete di default risulta in effetti "non attiva".
La posso anche attivare a mano e la cosa funziona, ma al riavvio di libvirt, risulta ancora non attiva:

Ecco cosa appare dopo aver avviato libvirt:

Codice: Seleziona tutto

# virsh net-list --all
 Nome      Stato        Avvio automatico   Persistent
-------------------------------------------------------
 default   non attivo   yes                yes

Allora provo ad avviarla manualmente:

Codice: Seleziona tutto

# virsh net-start default
Rete default avviata

# virsh net-list --all
 Nome      Stato    Avvio automatico   Persistent
---------------------------------------------------
 default   attivo   yes                yes

OK, rete default avviata.
Ora provo a riavviare il "servizio libvirt"

Codice: Seleziona tutto

# /etc/rc.d/rc.libvirt restart
Waiting for managedsave to finish on all guests...
Guests managed save took 2 seconds...
Stopping libvirtd...
Rete default distrutta

Stopping virtlogd...
Stopping virtlockd...
Starting virtlockd:  /usr/sbin/virtlockd -d
Starting virtlogd:  /usr/sbin/virtlogd -d
Starting libvirtd:  /usr/sbin/libvirtd -d

E verifico nuovamente lo stato della rete default:

Codice: Seleziona tutto

# virsh net-list --all
 Nome      Stato        Avvio automatico   Persistent
-------------------------------------------------------
 default   non attivo   yes                yes

Siamo punto e a capo quindi... nonostante la rete "default" sia configurata per attivarsi automaticamente, alla fine non risulta così: all'avvio di libvirt ha uno stato "non attivo".
In questo momento virt-manager e la macchina virtuale sono spenti.
Virt-manager non ha problemi ad avviarsi, invece se provo ad "eseguire" la macchina virtuale, se ne esce con l'errore "rete default non attiva".
Copio qui sotto un po' di dettagli:

Codice: Seleziona tutto

Errore nell'avvio del dominio: L'operazione richiesta non è valida: network 'default' is not active

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 72, in cb_wrapper
    callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 108, in tmpcb
    callback(*args, **kwargs)
  File "/usr/share/virt-manager/virtManager/object/libvirtobject.py", line 57, in newfn
    ret = fn(self, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/object/domain.py", line 1402, in startup
    self._backend.create()
  File "/usr/lib64/python3.9/site-packages/libvirt.py", line 1373, in create
    raise libvirtError('virDomainCreate() failed')
libvirt.libvirtError: L'operazione richiesta non è valida: network 'default' is not active

La soluzione manuale c'è: ogni volta che avvio libvirt, prima di lanciare la macchina virtuale con virt-manager, attivo la rete "default" col comando virsh riportato sopra.
A quel punto la rete è attiva e avviando la macchina virtuale non riscontro errori. Anche a sistema guest avviato, tutto sembra regolare, si riesce a navigare, a comunicare con l'host attraverso il bridge ecc ecc...

La domanda però resta:
cosa potrei controllare per capire dove sta il problema?
Perché quella rete "default", pur essendo impostata come "autostart", all'avvio di libvirt, risulta sempre disattivata?

questo te lo fa anche se riavvii completamente il pc?
ho avuto questo comportamento in passato aggiornando libvirt ma senza riavviare il pc.
in certi casi ho dovuto anche ricreare tutte le configurazioni da zero per risolvere il problema, facendo preventivamente un backup dei file delle macchine virtuali (e' spiegato nel README su SBo).

Sì me lo fa anche appena riavviato il PC, libvirt lo avvio a mano come utente root. Poi controllo lo stato della rete "default" e risulta inattiva nonostante sia marcata "yes" su "avvio automatico":

Codice: Seleziona tutto

# /etc/rc.d/rc.libvirt start
Starting virtlockd:  /usr/sbin/virtlockd -d
Starting virtlogd:  /usr/sbin/virtlogd -d
Starting libvirtd:  /usr/sbin/libvirtd -d

# virsh net-list --all
 Nome      Stato        Avvio automatico   Persistent
-------------------------------------------------------
 default   non attivo   yes                yes

La procedura che viene descritta nel Readme di SBo posso anche riprodurla, ma nel mio caso libvirt non è stato aggiornato di recente. Ho la stessa versione di SBo comunque, potrebbe anche essere che in fase di aggiornamento dalla versione precedente si sia rotto qualcosa e che sia rimasto rotto fino ad ora.

Codice: Seleziona tutto

# virsh --version
9.1.0

che comando usi per diventare root?
se non lo fai gia' (nel caso ignora questo messaggio) usa "su -", non sudo o su (senza il meno).

Sì sì, "su -" (c'ero già cascato in passato usando un alias basato su sudo ma avevo poi lasciato perdere perché dava anche lì problemi).

Ad ogni modo Ponce, se hai occasione di effettuare il breve test che ho postato lì sopra:

- avvio libvirt
- verifica stato rete default

Sempre che anche tu abbia una macchina virtuale in essere e che sia dotata di rete virtuale, ma dovrebbe essere il default...
Così mi confermi se da te risulta attivata automaticamente avviando libvirt oppure anche lì risulta non attiva pur essendo impostata per l'avvio automatico.

Grazie mille in anticipo!

si, la rete di default funziona appena avviato libvirt.

Niente, io continuo a rilevare il problema in oggetto anche dopo aver in pratica seguito la procedura descritta nel README di libvirt su SBo. Ho fatto una cosa un attimo diversa, ma la sostanza è quella:

Codice: Seleziona tutto

mkdir /tmp/libvirt-backup
cd /tmp/libvirt-backup
cp -r --parents /etc/libvirt/ .
cp -r --parents /var/lib/libvirt/ .
cp -r --parents /var/log/libvirt/ .
removepkg libvirt
rm -r /etc/libvirt
rm -r /var/lib/libvirt
rm -r /var/log/libvirt
installpkg /tmp/libvirt-9.1.0-x86_64-1_SBo.tgz
cp var/lib/libvirt/images/win7.qcow2 /var/lib/libvirt/images/
virsh define etc/libvirt/qemu/win7.xml

In pratica ho fatto un backup delle tre dirs indicate nel README.
Poi ho disinstallato il pacchetto libvirt e le ho rimosse dal sistema.
A questo punto ho reinstallato libvirt.
Ho copiato il file immagine del disco con windows 7 installato.
Ho poi eseguito il "define" di win7 attraverso virsh, grazie al file win7.xml che conteneva la configurazione del sistema guest backuppata in precedenza.

La rete default non può essere ripristinata esattamente come prima, perché all'installazione di libvirt viene ricreata ex-novo, con lo stesso nome di prima (default) ma con ID e Macaddr differenti. Ad ogni modo nel mio caso non dovrebbe rappresentare un problema per il guest dal momento che la rete default influisce sul sistema host tirando in piedi il vbr0 bridge virtuale, mentre il guest non fa altro che vedere questa rete default attraverso una sua scheda di rete virtuale.
In pratica è come se la rete default fosse un po' una sorta di scheda di rete presente sull'host, a cui poi il guest può collegarsi.

Dopo aver eseguito l'operazione dico subito che attivando a mano la rete "default" e successivamente avviando la macchina virtuale, sembra tutto ok. La connessione ad internet c'è ecc...

Il problema però resta, e anzi ne ho riscontrato 2 apparentemente differenti:
1. avviando libvirt la rete "default" non si avvia, risulta disattivata nonostante configurata come "auto start". Quindi stesso comportamento descritto nei post precedenti.
2. avviando manualmente la rete "default" con "virsh net-start default" ottengo un errore se sta funzionando "bind" (named).

In pratica per avviare la macchina virtuale devo:
- spegnere il servizio bind: /etc/rc.d/rc.bind stop
- avviare libvirt
- attivare la rete default
- ora posso riattivare bind: /etc/rc.d/rc.bind start
- e a questo punto faccio partire la macchina virtuale con virt-manager

Se avessi bind acceso e tentassi di avviare la rete default salta fuori un errore:

Codice: Seleziona tutto

# /etc/rc.d/rc.libvirt start
Starting virtlockd:  /usr/sbin/virtlockd -d
Starting virtlogd:  /usr/sbin/virtlogd -d
Starting libvirtd:  /usr/sbin/libvirtd -d


# virsh net-list --all
 Nome      Stato        Avvio automatico   Persistent
-------------------------------------------------------
 default   non attivo   yes                yes


# virsh net-start default
errore: Impossibile avviare la rete default
errore: internal error: Child process (VIR_BRIDGE_NAME=virbr0 /usr/sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default.conf --leasefile-ro --dhcp-script=
/usr/libexec/libvirt_leaseshelper) unexpected exit status 2:
dnsmasq: failed to create listening socket for 192.168.122.1: Address already in use

probabilmente hai bind gia' in ascolto sulla porta 53 dell'indirizzo 192.168.122.1?
ti conviene specificare su quali interfacce deve stare in ascolto con la direttiva listen-on nel file /etc/named.conf, in modo che non interferisca con dnsmasq che viene usato nelle interfacce virtuali: io per esempio ho questo pezzo di configurazione in quel file a questo scopo (le due interfacce indicate sono su due network privati)

Codice: Seleziona tutto

options {
[...]
        listen-on {
                 192.168.1.7;
                 192.168.3.1;
        };
};

se invece hai

Codice: Seleziona tutto

        listen-on { any; };

e' normale che ti faccia casino.

Bind mi fa da semplice DNS cache, sta in ascolto sul localhost. Diciamo che in pratica non ho toccato la configurazione di bind di slackware... Lo attivo così da sempre: quando era ancora in piedi il wiki di slacky c'era anche una piccola guida su come attivare il servizio, e la configurazione si limitava in pratica all'editing di "resolv.conf (nameserver 127.0.0.1)" se ben ricordo.

Se faccio un dig ad esempio verso google.com, tra i vari records si legge:

Codice: Seleziona tutto

;; SERVER: 127.0.0.1#53(127.0.0.1)

Quindi bind è in ascolto sul 127.0.0.1.

Il "named.conf" è intonso:

Codice: Seleziona tutto

//
// a caching only nameserver config
//
zone "." IN {
        type hint;
        file "caching-example/named.root";
};

zone "localhost" IN {
        type master;
        file "caching-example/localhost.zone";
        allow-update { none; };
};

zone "0.0.127.in-addr.arpa" IN {
        type master;
        file "caching-example/named.local";
        allow-update { none; };
};

EDIT:
No comunque hai ragione tu: 192.168.122.1 è il virtual bridge "virbr0" che mette in piedi libvirt. E di fatto fa riferimento sempre al sistema host, cioè è come se fosse 127,0.0.1. Ho provato a fare un "dig @192.168.122.1 google.com", e il server DNS interrogato risponde... è sempre la mia cache locale che risolve l'indirizzo. Per cui non so.

se vuoi essere sicuro che stia in ascolto solo su localhost allora specificalo nella sezione options di /etc/named.conf 127.0.0.1, tipo cosi'

Codice: Seleziona tutto

options {
[...]
        listen-on {
                 127.0.0.1;
        };
};

poi riavvialo e solo dopo controlla se riavviando libvirt hai il solito errore di prima.

Ho modificato come segue named.conf:

Codice: Seleziona tutto

options {
        directory "/var/named";
        listen-on {
                127.0.0.1;
        };
};

zone "." IN {
        type hint;
        file "caching-example/named.root";
};

zone "localhost" IN {
        type master;
        file "caching-example/localhost.zone";
        allow-update { none; };
};

zone "0.0.127.in-addr.arpa" IN {
        type master;
        file "caching-example/named.local";
        allow-update { none; };
};

Con questa configurazione named non risponde più se si interroga l'interfaccia di rete fisica della mia scheda di rete.
Per quanto riguarda invece l'indirizzo di rete di "virbr0" invece continua a redirigere la richiesta al localhost, cioè se eseguo un "dig @192.168.122.1 google.com" ecco che mi ritorna regolarmente l'IP, in pratica trova il server in ascolto comunque.
Però va be' virbr0 potrebbe essere un'interfaccia un po' "esotica" non so...

In ogni caso, la soluzione che hai suggerito sembra risolvere almeno uno dei due problemi, ovvero si riesce ad attivare la rete "default" con virsh senza errori, pur essendo in funzione il servizio bind/named:

Codice: Seleziona tutto

# /etc/rc.d/rc.bind restart
Stopping BIND:  /usr/sbin/rndc stop
Starting BIND:  /usr/sbin/named -u named


# /etc/rc.d/rc.libvirt start
Starting virtlockd:  /usr/sbin/virtlockd -d
Starting virtlogd:  /usr/sbin/virtlogd -d
Starting libvirtd:  /usr/sbin/libvirtd -d


# virsh net-list --all
 Nome      Stato        Avvio automatico   Persistent
-------------------------------------------------------
 default   non attivo   yes                yes


# virsh net-start default
Rete default avviata


# virsh net-list --all
 Nome      Stato    Avvio automatico   Persistent
---------------------------------------------------
 default   attivo   yes                yes

A creare l'interfaccia "virbr0" è proprio l'attivazione della rete default, viene creata dopo aver lanciato il comando "virsh net-start default". In definitiva resta il problemino del topic, ovvero come si vede anche da lì sopra, quando parte libvirt non si avvia automaticamente la rete default. Di conseguenza quando si avvia virt-manager e si esegue una macchina virtuale (credo lo faccia solo se dotata di scheda di rete che richiede virbr0 sull'host) questa non parte e salta fuori l'errore relativo la rete "default" non attiva.

Provo anche a fare l'upgrade di qemu da 7.2 a 8.2, non credo serva a nulla per il problema ma non si sa mai...

Ci sono degli sviluppi. Non so dire bene perché, non credo dipenda minimamente dall'upgrade di qemu... ma ho fatto una prova appena avviata slackware, quindi il sistema host.

Codice: Seleziona tutto

# /etc/rc.d/rc.libvirt start
Starting virtlockd:  /usr/sbin/virtlockd -d
Starting virtlogd:  /usr/sbin/virtlogd -d
Starting libvirtd:  /usr/sbin/libvirtd -d


# virsh net-list --all
 Nome      Stato    Avvio automatico   Persistent
---------------------------------------------------
 default   attivo   yes                yes

In pratica al primo avvio di libvirt, la rete "default" viene automaticamente avviata, come dovrebbe essere. Apparente il problema sembra risolto quindi... ma non è così: infatti se stoppo il servizio libvirt e lo riavvio, la rete default risulta nuvamente "non attiva". Quindi funziona bene solo al primo avvio di libvirt. Negli altri casi la rete default va avviata manualmente con "virsh net-start default".

PS.
Dopo la manovra di "reset & restore" seguando il README di libvirt. Mi sono accorto che dal sistema guest windows 7, non riesco più ad eseguire il ping verso il gateway (192.168.122.1), eppure dal sistema si naviga regolarmente sul web, ho anche provato il ping verso l'IP privato del mio router fisico e funziona... È come se guest e host non fossero più in rete tra loro, e che l'host facesse semplicemente da gateway verso il router fisico.
Di default virt-manager invece crea sul guest un'interfaccia di rete proprio per collegarsi alla rete "default". Di fatto il guest può raggiungere l'host via ping contattando l'indirizzo 192.168.122.1 che è l'ip dell'interfaccia virbr0 messa in piedi appunto sull'host. Questo permette ad esempio di condividere una directory del sistema windows guest e accedervi dall'host montandola via CIFS, molto utile per passare files tra host e guest.
Se avete qualche idea per riportare in funzione la comunicazione host guest via IP... perché soprattutto lato windows sono abbastanza ignorante in tema di reti. O comunque non so bene cosa può essersi rotto... prima il ping dal guest al IP del virbr0 funzionava, anche il mount cifs...
Aggiungo che invece dall'host il ping verso il'IP del guest funziona.

(magari non e' quello ma) quando hai ricompilato qemu hai installato anche libslirp e passato il parametro SLIRP=yes per attivare lo user mode networking?

Potrebbe essere, in effetti l'ho compilato via sbopkg un po' alla cieca. Riprovo anche aggiornando libslirp che vedo essere disponibile in versione più recente di quella installata adesso. Faccio sapere se si risolve almeno la comunicazione host-guest.

Resta il discorso libvirt. Se lo stoppo e lo avvio di nuovo, la rete "default" non risulta automaticamente attivata.
Invece riavviando l'intero sistema host slackware, e lanciando libvirt, la rete default viene regolarmente avviata.

slacky.eu

libvirt e default network autostart

libvirt e default network autostart

Re: libvirt e default network autostart

Re: libvirt e default network autostart

Re: libvirt e default network autostart

Re: libvirt e default network autostart

Re: libvirt e default network autostart

Re: libvirt e default network autostart

Re: libvirt e default network autostart

Re: libvirt e default network autostart

Re: libvirt e default network autostart

Re: libvirt e default network autostart

Re: libvirt e default network autostart

Re: libvirt e default network autostart

Re: libvirt e default network autostart

Re: libvirt e default network autostart