Perguntas[kvm-virtualization](server)

Estou tentando executar uma VM KVM/QEMU no RHEL9 que usa uma placa Infiniband (VF) virtualizada por meio de SR-IOV de um pool de VFs. Posso especificar um dispositivo PCI de VF específico com hostdev e isso funciona muito bem, no entanto, isso requer codificação rígida do barramento/slot/etc. PCI na planilha XML da VM. Isso seria um problema ao migrar a VM para outro servidor. Então, prefiro definir um pool de rede de VFs conforme descrito neste documento do RH que atribuiria uma VF livre a uma VM recém-iniciada automaticamente.

Fiz tudo conforme descrito nos documentos e o pool de rede de 8 VFs de uma única placa IB funciona como deveria:

# virsh net-dumpxml IB-passthrough
<network>
  <name>IB-passthrough</name>
  <uuid>8dce28fa-97ea-43d4-a82b-5923fa1a2a4f</uuid>
  <forward mode='hostdev' managed='yes'>
    <address type='pci' domain='0x0000' bus='0xc1' slot='0x00' function='0x1'/>
    <address type='pci' domain='0x0000' bus='0xc1' slot='0x00' function='0x2'/>
    <address type='pci' domain='0x0000' bus='0xc1' slot='0x00' function='0x3'/>
    <address type='pci' domain='0x0000' bus='0xc1' slot='0x00' function='0x4'/>
    <address type='pci' domain='0x0000' bus='0xc1' slot='0x00' function='0x5'/>
    <address type='pci' domain='0x0000' bus='0xc1' slot='0x00' function='0x6'/>
    <address type='pci' domain='0x0000' bus='0xc1' slot='0x00' function='0x7'/>
    <address type='pci' domain='0x0000' bus='0xc1' slot='0x01' function='0x0'/>
  </forward>
</network>

Escrevo a seguinte entrada no XML da VM:

<interface type='network'>
  <source network='IB-passthrough'/>
</interface>

Mas depois de fechar o editor XML, a entrada é automaticamente estendida com entradas mace :address

<interface type='network'>
  <mac address='52:54:00:44:db:0d'/>
  <source network='IB-passthrough'/>
  <address type='pci' domain='0x0000' bus='0x07' slot='0x00' function='0x0'/>
</interface> 

Então a VM não pode ser iniciada porque o MAC não pode ser definido:

# virsh start rhel9.2-testvm
    error: Failed to start domain 'rhel9.2-testvm'
    error: Cannot set interface MAC to 52:54:00:05:72:5c for ifname ibp193s0 vf 0: Operation not supported

Existe uma maneira de omitir esse MAC automático? Ou a mudança do Interface MAC? Ou há outro problema que estou esquecendo?

Estou trabalhando com o Ubuntu 24.04 Desktop e criei uma VM conectada à libvirt-NAT-Bridge padrão e uma segunda rede isolada.

A rede em ponte é virbr0: 192.168.122.0/24o host obtido 192.168.122.1e a VM obtida estática 192.168.122.128. A rede isolada é 10.95.212.0/24.

Quero poder fazer ping/ssh em hosts na rede isolada, por isso configurei uma rota estática ( route add ...) no host. Funciona, mas não sobreviveu a uma reinicialização. Tentei, nmtuimas a rota desaparece na reinicialização.

Pensei em virsh net-edit default, mas não encontrei nenhuma documentação sobre como fazer isso.

Onde devo definir a rota para que ele sobreviva à reinicialização?

É possível excluir um instantâneo de uma imagem QCOW2 sem desligar uma máquina virtual (QEMU+KVM)? A execução não qemu-img snapshot -d ...quebraria a consistência dos dados? Em caso afirmativo, isso quebraria a consistência se alguém fosse executado virsh pause ...antes de excluir um instantâneo e depois executado virsh resume ...? O que você acha?

Obrigado!

Estou executando um convidado do Windows no Proxmox VE 8.2 (no Debian 12) e gostaria de ocultar do convidado informações sobre o hardware físico subjacente.

Motivação

Paguei o preço total por uma licença perpétua para alguns softwares de gerenciamento de inventário que chegaram ao "fim da vida útil" para suporte e o fornecedor decidiu desligar seu servidor de licenças. Eles me emitiram um certificado de acesso offline, mas o problema é que:

1. o certificado será invalidado se o aplicativo Windows (na minha máquina) detectar alterações no hardware subjacente.
2. se eu reinstalar o aplicativo, não tenho conhecimento de nenhum mecanismo para importar um certificado emitido anteriormente.

Para reduzir as chances de o aplicativo detectar grandes alterações de hardware, instalei o aplicativo em uma máquina virtual Windows. (O host é KVM no Linux.) Gostaria de ter liberdade para migrar a VM para diferentes máquinas físicas, atualizar o hardware no PC que executa o hipervisor etc., sempre que necessário.

Hardware conforme percebido pela VM

Desconheço o algoritmo usado pelo aplicativo para detectar alterações de hardware, mas suspeito que ele possa analisar coisas como:

• Número de série da CPU
• endereços MAC de interface de rede
• Sequências do BIOS
• UUID do disco rígido

Algumas dessas informações (por exemplo, as informações da CPU vistas no aplicativo Informações do sistema do Windows) parecem ser obtidas do host da VM e transmitidas ao convidado pelo hipervisor.

Você pode me dizer quais configurações do Proxmox (ou Qemu/KVM) devo ajustar para ocultar (ou substituir ou congelar) os identificadores de hardware visíveis para o convidado da VM?

Eu tenho um servidor Ubuntu 22.04 dedicado na Hetzner rodando KVM. Atribuí endereços IP de uma sub-rede adicional às VMs convidadas. Posso acessar as VMs convidadas por meio de seus endereços IP públicos conforme pretendido.

Recebi um e-mail da Hetzner dizendo que estou usando endereços Mac "não permitidos" e ameaçando bloquear o servidor. Os endereços MAC "não permitidos" pertencem às VMs convidadas. O suporte da Hetzner diz "Você deve ter certeza de que nenhum endereço MAC de suas VMs ficará visível com o uplink público em seu dispositivo de rede." Alguém sabe como cumprir as regras de rede da Hetzner? Aqui está minha configuração:

1. SERVIDOR FÍSICO

$ sudo cat /etc/netplan/01-netcfg.yaml
    ### Hetzner Online GmbH installimage
    network:
      version: 2
      renderer: networkd
      ethernets:
        enp98s0f0:
          match:
            macaddress: xx:xx:xx:xx:xx:fa
          dhcp4: no
          dhcp6: no
      bridges:
        br0:
          macaddress: xx:xx:xx:xx:xx:fa
          interfaces:
            - enp98s0f0
          dhcp4: no
          dhcp6: no
          addresses:
            - aa.bb.cc.108/32 # Physical NIC (Main IP)
            - aa.bb.cc.65/28 # First usable IP of the additional subnet
          routes:
            - to: 0.0.0.0/0
              via: aa.bb.cc.105 # Gateway for Main IP on physical NIC
              on-link: true
            - to: aa.bb.cc.64/28 # Additional subnet
              via: aa.bb.cc.65 # First usable IP of the additional subnet assigned to physical NIC above
              on-link: true
          nameservers:
            addresses:
              - 185.12.64.2
              - 185.12.64.1
          parameters:
            stp: false
            forward-delay: 0

$ cat /etc/sysctl.d/10-forwarding.conf 
net.ipv4.ip_forward=1
#net.ipv4.conf.enp98s0f0.send_redirects=0
net.ipv4.conf.all.proxy_arp=1
net.ipv4.conf.all.forwarding=1

$ cat br0.xml
<network>
    <name>br0</name>
    <forward mode='bridge'/>
    <bridge name='br0'/>
</network>

2. VM CONVIDADA

$ sudo cat /etc/netplan/01-netcfg.yaml
# This is the network config written by 'subiquity'
network:
  ethernets:
    enp1s0:
      addresses:
      - aa.bb.cc.67/28 # Additional subnet
      nameservers:
        addresses:
        - 185.12.64.2
        - 185.12.64.1
        search: []
      routes:
      - to: default
        via: aa.bb.cc.65 # First usable IP of the additional subnet assigned to physical NIC
  version: 2

Qual elemento em um vagrant-libvirt-qemu/kvm-chain é responsável por realmente configurar a VM? Como editar os arquivos de configuração de rede. Isso não dependeria totalmente dos detalhes do sistema operacional da VM?

Como exemplo, obtive as seguintes linhas no arquivo Vagrantfile:

config.vm.box = "archlinux/archlinux"
config.vm.network :private_network, :libvirt__network_name => "default", :mac => "52:54:00:00:00:1f", :ip => "192.168.30.7"

... e a VM termina com o dhcpcd (o daemon do cliente) em todas as interfaces, enquanto o systemd networkctlmostra que ele gerencia todas as interfaces (uma com configuração estática, claramente em conflito com o dhcpcd). -- Apenas um deles deve ser responsável por qualquer interface...

Então, qual entidade colocou os arquivos /etc/systemd/network? Como essa entidade tinha tanta certeza de que o systemd estava sendo usado naquela VM? Essa entidade (que gira os botões da configuração da VM) está documentada em algum lugar com esses detalhes?

Eu tenho um host executando o Proxmox com algumas VMs. Devido a alguma imprevisibilidade com o uso de memória de alguns aplicativos e ao desejo de fornecer memória a algumas VMs (como um banco de dados) para o cache de páginas quando havia memória disponível, provisionei memória em excesso.

Tentei testar a confiabilidade dessa configuração tentando usar mais memória no total do que o host possui, e esse OOM eliminou a VM, em vez de tentar recuperar o cache da página das outras VMs.

Há algo que eu possa fazer para permitir que o driver do balão recupere a memória ou estou entendendo mal como funciona o balão de memória?

Tenha um host Ubuntu Server dedicado com uma única interface de rede, mas com dois endereços IP:

root@server:~# cat /etc/netplan/50-cloud-init.yaml 
network:
    version: 2
    ethernets:
        eno3:
            dhcp4: true
            match:
                macaddress: 00:00:00:00:00:00
            set-name: eno3
            addresses: [IP-A/24, IP-B/32]

Quando IP-Aé o endereço IP nativo atribuído ao servidor e IP-Bé um endereço IP adicional que contratei. Ao configurar usando netplan applytudo funciona muito bem, o servidor WEB sai pelo endereço IP IP-Ae pelo curl consigo ver como é possível acessar a internet de IP-B:

wget -qO- http://checkip.dyndns.com/ --bind-address IP-A
... Current IP Address: IP-A
wget -qO- http://checkip.dyndns.com/ --bind-address IP-B
... Current IP Address: IP-B

O problema é que também tenho uma máquina virtual com kvm( virsh), como posso fazer a máquina virtual sair para a internet usando IP-Be não IP-Acomo faz por padrão?

Minhas interfaces de rede:

root@yhojann:~# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: eno3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 11:11:11:11:11:11 brd ff:ff:ff:ff:ff:ff
    inet IP-A/24 brd x.x.x.255 scope global dynamic eno3
       valid_lft 63801sec preferred_lft 63801sec
    inet IP-B/32 scope global eno3
       valid_lft forever preferred_lft forever
    inet6 ffff::fff:ffff:ffff:ffff/64 scope link 
       valid_lft forever preferred_lft forever
3: eno4: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 22:22:22:22:22:22 brd ff:ff:ff:ff:ff:ff
17: virbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 33:33:33:33:33:33 brd ff:ff:ff:ff:ff:ff
    inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
       valid_lft forever preferred_lft forever
18: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel master virbr0 state DOWN group default qlen 1000
    link/ether 44:44:44:44:44:44 brd ff:ff:ff:ff:ff:ff
20: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master virbr0 state UNKNOWN group default qlen 1000
    link/ether 44:44:44:44:44:44 brd ff:ff:ff:ff:ff:ff

Eu tentei descobrir se é possível configurar a rede kvm usandovirsh net-edit default

mas não encontrei nenhuma referência que permita fazer uso de um endereço ip de saída específico do host principal sem ter que usar uma nova interface virtual e redirecionar pacotes com iptables, pois isso causa uma grande latência na conectividade.

Existe uma maneira mais "nativa" de dizer ao kvm para usar o IP específico?

Os endereços IP e endereços mac mostrados são apenas para referência. Eu utilizo o ufw para gerenciar as conexões.

Se três virtio-blkdispositivos forem adicionados, a VM falhará no meio da inicialização do Windows 10. O anexo blockdevnão tem influência. A VM está funcionando bem usando dois arquivos virtio-blk.

qemu-system-x86_64 \
...
-device virtio-blk,drive=c,bus=pci.3,addr=0x0,write-cache=on,bootindex=1 \
-device virtio-blk,drive=d,bus=pci.4,addr=0x0,write-cache=on \
-device virtio-blk,drive=e,bus=pci.5,addr=0x0,write-cache=on \
...

qemu-system-x86_64sai sem imprimir nenhuma informação. Como depurar nesta situação? Talvez existam razões conhecidas pelas quais isso está acontecendo.

Contexto: Kubernetes, contêiner Debian privilegiado, Qemu 5.2.0

O libvirt é capaz de fazer uma migração de armazenamento ao vivo, mas mantém a VM no mesmo host?

Eu tenho dois pools de sistemas de arquivos NFS Network em um host. Eu gostaria de migrar ao vivo os arquivos de disco qcow2 subjacentes de um pool para o outro.

Não consigo encontrar nenhuma documentação relacionada apenas à migração de armazenamento ao vivo. Todos os exemplos e documentação parecem exigir uma migração de VM ao vivo ao mesmo tempo.