I think you are good on the files of dnsmasq, I missed that those are the
complete files indeed.
I beg your pardon for doing too much things at once.
Thanks for the upstream issue, I subscribed there to keep on track.
But there I can see right what I assumed:
kubic-kvm git:(kubic-kvm) ✗ cat /var/lib/libvirt/dnsmasq/virbr2.status
[
{
"ip-address": "10.17.3.1",
"mac-address": "02:f7:b7:f1:f8:ac",
"hostname": "kubic-kubadm-1",
"client-id": "ff:00:3a:4f:e1:00:01:00:01:23:11:25:f0:52:54:00:3a:4f:e1",
"expiry-time": 1535108104
}
]
A "normal" file like that with three IPs would look like:
$ cat /var/lib/libvirt/dnsmasq/virbr0.status
[
{
"ip-address": "192.168.122.219",
"mac-address": "52:54:00:b2:ae:fb",
"hostname": "c-nested-kvm-4",
"client-id": "ff:b5:5e:67:ff:00:02:00:00:ab:11:c6:ad:76:18:90:c7:81:55",
"expiry-time": 1535535182
},
{
"ip-address": "192.168.122.29",
"mac-address": "52:54:00:7a:a2:2c",
"hostname": "ubuntu",
"client-id": "ff:b5:5e:67:ff:00:02:00:00:ab:11:80:9a:8b:2c:bb:a0:3c:4f",
"expiry-time": 1535535717
},
{
"ip-address": "192.168.122.115",
"mac-address": "52:54:00:84:73:30",
"hostname": "ubuntu",
"client-id": "ff:b5:5e:67:ff:00:02:00:00:ab:11:c9:39:1d:b7:27:3a:78:72",
"expiry-time": 1535536174
}
]
That again points to client-id (or similar) as the potential source.
For the virsh console issue, that must be with the way terraform sets up the
guests.
Can't help with that atm - you might look at the following and check
console/pty setup:
$ virsh dumpxml <guestname>
I'd expect something like:
<serial type='pty'>
<source path='/dev/pts/3'/>
<target type='isa-serial' port='0'>
<model name='isa-serial'/>
</target>
<alias name='serial0'/>
</serial>
<console type='pty' tty='/dev/pts/3'>
<source path='/dev/pts/3'/>
<target type='serial' port='0'/>
<alias name='serial0'/>
</console>
But overall this isn't the issue of this bug, and since they get IP and you can
log in you are fine. The "virsh console" suggestion was only in case you could
not log in.
About the network config for a start the following should do the trick:
$ virsh net-dumpxml kubic-dev-net
To get insight how terraform has set this up in libvirt.
But given the Data so far it points more and more to client-id.
Although to admit, I'd have expected them all to get the same IP in this case.
Never the less, having only one entry in the .status file indicates something
is wrong.
This is based on
https://www.freedesktop.org/software/systemd/man/systemd.network.html
The Client-ID is based on:
- a prefix ff:56:50:4d:98:00:02:00:00:
- vendor systemd ab:11
- machine-id
So if machine ID is not unique, we have a problem - it should be (for more
reasons than dhcp).
See: https://www.freedesktop.org/software/systemd/man/machine-id.html#
You can check it like this:
$ cat /etc/machine-id
That should be different in each of your guests - is it different?
Since networkd can be configured to use other entries as client-id it might
also be worth to check:
$ grep -Hn ClientIdentifier /*/systemd/network/*
In general it can't hurt to show the guests POV of network configuration.
Output of:
$ networkctl status; networkctl
And maybe tar all of "/*/systemd/network/*" up and attach it here.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1788841
Title:
incomplete output of `virsh net-dhcp-leases`
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1788841/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
