Forum Linux.général KVM, réseau / résolu

Posté par  . Licence CC By‑SA.
Étiquettes :
1
14
juin
2023

Bonjour,
Je patauge avec un problème de connexion, et comme je ne suis familier ni avec KVM ni avec le réseau, je ne m'en sors pas.

Je veux installer HomeAssistant OS dans une machine virtuelle. La machine hôte est une Centos8 stream à jour qui me sert de NAS et autres bricoles, headless, en réseau local: j'ai juste un accès ssh.

L'image KVM est téléchargée. L'hôte est en IP fixe.

Voilà les interfaces.

ip -4 addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: enp8s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    inet 192.168.1.100/24 brd 192.168.1.255 scope global noprefixroute enp8s0
       valid_lft forever preferred_lft forever
4: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    inet 192.168.122.100/24 brd 192.168.122.255 scope global noprefixroute virbr0
       valid_lft forever preferred_lft forever

Première interrogation: est-ce qu'il faut lancer virt-install en user ou en root (sudo)?

Ensuite je tente.

sudo virt-install --name hass --description "Home Assistant OS" --os-variant=generic --ram=2048 --vcpus=2 --disk /var/lib/homeassistant/haos_ova-10.1.qcow2,bus=sata --graphics none --boot uefi --network bridge=virbr0,model=virtio
L'image démarre, je me logge (root / pas de mdp), et je fais ha banner:

    System information
    IPv4 addresses for enp1s0: 

    OS Version:               Home Assistant OS 10.1
    Home Assistant Core:      2023.6.1

    Home Assistant URL:       http://homeassistant.local:8123
    Observer URL:             http://homeassistant.local:4357

C'est pas bon, quand j'ai fais un test sur mon portable j'avais une addresse ipv4. Je m'attendais à avoir 192.168.122.100/24.

J'ai tenté en utilisant la configuration"default", c'est à dire sans spécifier --network bridge=virbr0,model=virtio, mais pas mieux.

J'ai tenté diverses incantations pour essayer de comprendre.

ip link show type bridge
6: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000
link/ether 52:54:00:f6:35:b4 brd ff:ff:ff:ff:ff:ff

ip link show master virbr0
(rien)

Edition avec sudo nmtui, ajout d'un "slave" sur virbr0 (qui était vide) en choisissant enp8s0 (au passage je change l'IP de virbr0 à 192.168.1.130)

Il y a pas mal d'info sur KVM, libvirt bridges ( https://lukas.zapletalovi.com/posts/2015/fedora-22-libvirt-with-bridge/ , https://linuxconfig.org/how-to-use-bridged-networking-with-libvirt-and-kvm ) mais je n'arrive pas à comprendre ce qui est pertinent dans mon cas.

Bref, je patauge. Je ne sais plus ou j'en suis. Comment faire pour que ma machine virtuelle ait un IP fixe sur mon réseau local ?

Merci pour votre aide !

  • # pas besoin de virt-install

    Posté par  (site web personnel, Mastodon) . Évalué à 2.

    il suffit de placer ton qcow2 là où tu les mets d'habitude, ensuite dans virt-manager tu crée une VM et tu lui dit d'utiliser un disque existant.

    Un gentil du net

    • [^] # Re: pas besoin de virt-install

      Posté par  . Évalué à 1.

      merci, mais je n'ai pas de configuration pre-existante, c'est la première fois que j'utilise KVM.

      Et je ne peux pas utiliser virt-manager, il n'y a pas d'interface graphique sur cette machine. La VM est créée, elle tourne. C'est juste que je n'ai pas la bonne configuration de réseau.

      • [^] # Re: pas besoin de virt-install

        Posté par  (site web personnel, Mastodon) . Évalué à 1.

        tu peux installer virt-manager sur ton poste de travail (avec interface graphique) et le configurer pour se connecter à un serveur distant (sans interface graphique) via SSH

        virt-manager s'occupe de te créer ton modèle de machine virtuelle, tout ce que tu as besoin de faire c'est lui fournir ton image qcow2.

        Un gentil du net

  • # Bridge

    Posté par  . Évalué à 2.

    pour les machines virtuelles, je crée un bridge, et je met la carte réseau de la machine physique dedans.

    Si tu n'as qu'une carte réseau, il faut donner une IP au bridge pour accéder à ta machine.

    Je l'ai toujours fait sur Debian, alors je n'ai pas la méthode Centos, mais tu devrais trouver facilement.

    Ensuite, tu affectes le bridge créé à tes machines virtuelles comme dans ton exemple.
    Sauf qu'au lieu de virbr0, tu donnes le nom du bridge que tu auras choisi en le créant.

  • # NAT ou pas NAT

    Posté par  . Évalué à 3.

    ta machine physique est en 192.168.1.x/24
    ton bridge est en 192.168.122.x/24

    quand tu met ta VM sur le bridge elle recoit une IP 192.168.122.x/24
    elle n'est pas sur le meme reseau que la machine physique

    elle est joignable depuis cette meme machine car cette derniere est connectée sur les deux reseaux.

    si tu veux joindre ta VM depuis l'exterieur, il faut que tu renvoies certains ports de la machine physique vers la VM (Port Forwarding)

    ou bien alors il faut que ton bridge soit un vrai bridge sur enp8s0,
    cette carte devient alors inactive, et c'est le virbr0 qui prendre l'IP 192.168.1.x/24 et mettra ta VM sur le meme reseau

  • # bridge

    Posté par  . Évalué à 2.

    Merci pour votre aide. La résolution a consisté à créer un bridge, et à ne pas s’intéresser a KVM, ou virt-manager ou virt-install tant que le bridge ne fonctionnait pas.

    Ce qu'il me manquait dans le bridge, c'est que enp8s0 n'était pas down.

    nmcli connection down enp8s0

    Les pages qui m'ont aidé:

    https://www.cyberciti.biz/faq/centos-8-add-network-bridge-br0-with-nmcli-command/

    https://www.tecmint.com/create-network-bridge-in-rhel-centos-8/

    https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_and_managing_networking/configuring-a-network-bridge_configuring-and-managing-networking

    merci !

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.