uvt-kvm assumes network is on virbr0

[David A. Desrosiers]

This is very similar to bug #1428674, but slightly different, and easily reproduced. With a solution below!

When creating cloud images using 'uvt-kvm create myvm', it will incorrectly assert that the 'default' network is on vibr0, and when the VM boots, net-dhcp-leases will show its hostname as 'ubuntu' instead of 'myvm', despite the VM's hostname itself, being 'myvm'.

$ uvt-kvm ssh ubuntu@myvm --insecure
[12:39:55] <setuid> uvt-kvm: error: no IP address found for libvirt machine u'myvm'. Has it had time to boot yet?

If you interactively ssh into the VM (requires passing '--password foobar' to the 'uvt-kvm create' command), you can see that it does indeed have an IP address

$ ssh ubuntu@10.0.5.190 "hostname -f; hostname -I"
myvm
10.0.5.190

If you ssh into the guest (myvm) and then look at /etc/hosts, you'll notice the last line has an incorrect entry, pointing the loopback address to the hostname of 'myvm'. This is always wrong.

Manually editing that to correctly point 10.0.5.190 to myvm, and rebooting the VM, then allows virsh net-dhcp-leases to correctly show 'myvm' in the list (vs. 'ubuntu' before), but 'uvt-kvm ssh --insecure myvm' still fails.

$ sudo virsh --connect qemu:///system net-dhcp-leases default
 Expiry Time MAC address Protocol IP address Hostname Client ID or DUID
-------------------------------------------------------------------------------------------------------------------
2016-08-02 13:41:34 52:54:00:9d:ec:32 ipv4 10.0.5.190/24 myvm -

I destroyed this VM, and edited the networks to make 'default' reside on vibr0 (using 'virsh net-edit'), then destroyed (stopped) those networks and restarted them.

Now creating the vm using 'uvt-kvm create' as before, produces a 'myvm' that shows up in net-dhcp-leases (without editing /etc/hosts and rebooting), AND 'uvt-kvm ssh --insecure myvm' works perfectly as expected.

The bug with /etc/hosts is still present, but I'll file that separately.

The solution to this would be to have uvt-kvm use 'net-dumpxml default', parse the bridge out of the 'default' network and scan that for leases. It does not do that today.

<network>
  <name>default</name>
  <uuid>dabf43c6-e876-436b-9a03-fcc7ede8619f</uuid>
  <forward mode='nat'>
    <nat>
      <port start='1024' end='65535'/>
    </nat>
  </forward>
  <bridge name='virbr3' stp='on' delay='0'/>
  <mac address='52:54:00:4d:b7:28'/>
  <domain name='default'/>
  <ip address='10.0.5.1' netmask='255.255.255.0'>
    <dhcp>
      <range start='10.0.5.128' end='10.0.5.254'/>
    </dhcp>
  </ip>
</network>

Not everyone will have 'default' at vibr0, so we need to accommodate configurations where that isn't the first, or required bridge.

[Christian Ehrhardt  (paelzer)]

Working through old bugs atm.

@Rbasak - this is aging for quite a while being ubuntu-server subscribed.
Do you think this would fit into your work this cycle?
If not we should mention here what we expect - maybe even unsubscribe ubuntu-server and leave it up for the community.

[Robie Basak (racb)]

I'm catching up with triage on old uvtool bugs.

I agree that this use case is currently not supported. I'm marking it Wishlist though, because uvtool can't possibly handle all libvirt use cases, and so expanding use case support is always Wishlist.

[Rafael David Tinoco (rafaeldtinoco)]

$ virsh net-dumpxml default | grep bridge

  <bridge name='kvm' stp='off' delay='0'/>

shall be enough to replace LIBVIRT_DNSMASQ_STATUS_FILE in order for libvirt_dnsmasq_status_file_mac_to_ip() to read the correct status file.

[Robie Basak (racb)]

On Tue, Nov 19, 2019 at 04:20:19PM -0000, Rafael David Tinoco wrote:
> ...shall be enough to replace LIBVIRT_DNSMASQ_STATUS_FILE in order for
> libvirt_dnsmasq_status_file_mac_to_ip() to read the correct status
> file.

+1 on that approach. Even though uvtool doesn't typically run
privileged, perhaps it would be wise to sanitize the bridge name anyway
before looking for the file on the filesystem just to be safe. Perhaps
limit it to [A-Za-z0-9]? Or \w, in case users have unicode bridge names
(!)?