Public bug reported:

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 [email protected] "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.

** Affects: uvtool (Ubuntu)
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1609072

Title:
  uvt-kvm incorrectly asserts 'default' will be on vibr0, and
  ssh/networking fails

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/uvtool/+bug/1609072/+subscriptions

-- 
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to