Re: virsh domifaddr --domain domname --source {lease, arp} not showing results with ipv6

[Natxo Asenjo <natxo.asenjo@xxxxxxxxx>]

hi,

On Tue, Mar 21, 2023 at 3:40 PM Michal Prívozník <mprivozn@xxxxxxxxxx> wrote:

On 3/19/23 20:21, Natxo Asenjo wrote:
> hi,
>
> I have configured a routed network on my laptop with a ipv6 subnet and
> dnsmasq is handing out ipv6 addresses to my vms and it works really wel,
> but finding out which ips have been used is not as easy as with ipv4.
>
> [root@lenovo ~]# virsh domifaddr --domain wec --source lease
>  Name       MAC address          Protocol     Address
> -------------------------------------------------------------------------------
>
> [root@lenovo ~]# virsh domifaddr --domain wec --source arp
>  Name       MAC address          Protocol     Address
> -------------------------------------------------------------------------------
>
> When using a ipv4 network, this works:
>
> root@lenovo ~]# virsh domifaddr --domain evenng --source arp
>  Name       MAC address          Protocol     Address
> -------------------------------------------------------------------------------
>  vnet2      52:54:00:4c:83:98    ipv4         192.168.122.229/0
> <http://192.168.122.229/0>
>
> [root@lenovo ~]# virsh domifaddr --domain evenng --source lease
>  Name       MAC address          Protocol     Address
> -------------------------------------------------------------------------------
>  vnet2      52:54:00:4c:83:98    ipv4         192.168.122.229/24
> <http://192.168.122.229/24>
>
> I can obviously look into the leases file and find out the address, but
> it would be nice to be able to use the virt tooling.

Looks like you won't find any info for IPv6 there, because that's
exactly what '--source lease' is doing. Are you sure that your IPv6
address is not autoconfigured and it indeed is libvirt spawned dnsmasq
that's assigning the IPv6 address?

this is the xml:

# cat networks/ipv6.xml
<!--
WARNING: THIS IS AN AUTO-GENERATED FILE. CHANGES TO IT ARE LIKELY TO BE
OVERWRITTEN AND LOST. Changes to this xml configuration should be made using:
  virsh net-edit ipv6
or other application using the libvirt API.
-->

<network>
  <name>ipv6</name>
  <uuid>49957183-e4e4-4541-8746-11be67f0a511</uuid>
  <forward mode='open'/>
  <bridge name='virbr1' stp='on' delay='0'/>
  <mac address='52:54:00:09:8e:66'/>
  <domain name='ipv6'/>
  <ip family='ipv6' address='2a02:xxx:xx:7::1' prefix='64'>
    <dhcp>
      <range start='2a02:xxx:xx:7::100' end='2a02:xxx:xx:7::1ff'/>
    </dhcp>
  </ip>
</network>

so it looks like a dhcp server to me ;-)

I just found out about virsh net-dhcp-leases and that one lists the leases:

# virsh net-dhcp-leases --network ipv6
 Expiry Time           MAC address         Protocol   IP address                Hostname          Client ID or DUID
---------------------------------------------------------------------------------------------------------------------------------------------
 2023-03-22 16:35:44   52:54:00:0e:ee:da   ipv6       2a02:xxx:xx:7::1ba/64   WIN-C0HD8RH61MI   00:01:00:01:2b:a7:05:c5:52:54:00:0e:ee:da

For the '--source arp' case - libvirt reads the arp table (effectively
the same info is exposed under /proc/net/arp file) and finds a matching
entry there, based on the MAC address. Can you see whether there's a match?

No, that only entry right now there is my router:

]# cat /proc/net/arp
IP address       HW type     Flags       HW address            Mask     Device
xx.x.x.1         0x1         0x2         cafebabecafe     *        wifi0

 

And lastly - there's '--source agent' which is most likely to return
useful information, but that requires guest agent running inside.

Indeed, no agent running on the vm, could add it.

Michal

>
> This is on a fedora 37 running qemu-kvm-7.0.0-14.fc37.x86_64 and
> dnsmasq-2.89-1.fc37.x86_64, everything intalled from the fedora
> repositories.


So is it safe to assume that libvirt (which is where you're reporting
the issue) is: libvirt-8.6.0-5.fc37 ?

yes: libvirt-8.6.0-5.fc37.x86_64

 

Michal

So dumping the net-dhcp-leases works also for me, it's just not consequent with the ipv4 behaviour, that's all.

--
regards,
natxo