I took a step back from doing bisecting and focussed on creating a replication scenario, which I've done successfully.
ipconfig is struggling to handle things when two interfaces are present and sending out DHCP requests, even if one interface doesn't get a response.
Here's what I've done:
Using virt-manager I created a bridge, bridge1, with no IP range associated with it (I want dnsmasq on a host to handle IP). I created a second, bridge2, likewise with no IP range associated with it ready for later use.
I created an instance, named primary, with two NICs, one doing the usual NAT stuff so it has internet access. One hooked up to bridge1. I gave it two storage devices, 1 (sda) at 15Gb in size to act as local storage, 1 (sdb) 40Gb in size to be hosted over iSCSI (in hindsight, no reason for it not to be 15Gb too).
Install Ubuntu 16.04.1 LTS on the primary instance, pretty much following through with defaults, but leaving the second hard drive unused. Reboot and bring up the instance. In my case I end up with ens3 being the NATing interface, ens9 being hooked up to the bridge interface.
##########################
sudo apt update
sudo apt upgrade
##########################
Add to /etc/network/interfaces:
auto ens9
iface ens9 inet static
address 192.168.0.1/24
No storage. Attach Ubuntu 16.04.1 LTS iso to the instance to boot from initially. Two NICs, first attached to bridge1. Second attached to bridge2.
Go through the installation procedure, logging in to the iscsi endpoint on 192.168.0.1, using the details above (no username/password necessary with this configuration) and install to the iSCSI target. At the end, detach the CD-ROM and ensure everything is set up to network boot.
On start-up you should see it network boot happily, everything is awesome. Do a "sudo apt update" and "sudo apt upgrade". Then reboot.
On start-up you should see the bug happening. ipconfig is sending out DHCP requests on both interfaces and failing to accept any responses it is being sent ("journalctl -xef -u dnsmasq" on primary shows it is sending them). If you remove that second NIC, you'll see that the instance is able to boot happily.
I took a step back from doing bisecting and focussed on creating a replication scenario, which I've done successfully.
ipconfig is struggling to handle things when two interfaces are present and sending out DHCP requests, even if one interface doesn't get a response.
Here's what I've done:
Using virt-manager I created a bridge, bridge1, with no IP range associated with it (I want dnsmasq on a host to handle IP). I created a second, bridge2, likewise with no IP range associated with it ready for later use.
$$$$$$$ $$$$$$$ $$$$$$$ $$$$$$$ $$$$$$$ $$$$$$$ $$$$$$$ $$$$$$$ $$$$$$$ $$$$$$$ $
I created an instance, named primary, with two NICs, one doing the usual NAT stuff so it has internet access. One hooked up to bridge1. I gave it two storage devices, 1 (sda) at 15Gb in size to act as local storage, 1 (sdb) 40Gb in size to be hosted over iSCSI (in hindsight, no reason for it not to be 15Gb too).
Install Ubuntu 16.04.1 LTS on the primary instance, pretty much following through with defaults, but leaving the second hard drive unused. Reboot and bring up the instance. In my case I end up with ens3 being the NATing interface, ens9 being hooked up to the bridge interface.
####### ####### ####### #####
sudo apt update
sudo apt upgrade
####### ####### ####### #####
Add to /etc/network/ interfaces:
auto ens9
iface ens9 inet static
address 192.168.0.1/24
####### ####### ####### #####
Then:
sudo apt install open-iscsi targetcli dnsmasq
####### ####### ####### #####
dnsmasq config:
log-queries 192.168. 0.50,192. 168.0.150, 12h script. ipxe
log-dhcp
interface=ens9
dhcp-range=
dhcp-boot=
enable-tftp
tftp-root=/tftpd
tftp-no-fail
####### ####### ####### #####
Then run targetcli and do the following commands:
backstores/iblock create uefi /dev/sdb 02.oracle. boot:uefi 02.oracle. boot:uefi/ tpg1 block/uefi write_protect= 0 generate_ node_acls= 1 cache_dynamic_ acls=1
/iscsi create iqn.2015-
cd iqn.2015-
luns/ create /backstores/
portals/ create 0.0.0.0
set attribute authentication=0 demo_mode_
exit
####### ####### ####### #####
sudo mkdir /tftpd
sudo chown dnsmasq: /tftpd
####### ####### ####### #####
/tftpd/script.ipxe:
#!ipxe 02.oracle. boot:uefi 168.0.1: :::iqn. 2015-02. oracle. boot:uefi
set initiator-iqn iqn.2015-
sanboot iscsi:192.
####### ####### ####### #####
This gets the host pretty much ready to be an iscsi target for a host. The host has been patched etc, so reboot.
You may want to set up ip forwarding etc on this instance.
$$$$$$$ $$$$$$$ $$$$$$$ $$$$$$$ $$$$$$$ $$$$$$$ $$$$$$$ $$$$$$$ $$$$$$$ $$$$$$$ $
Second host:
No storage. Attach Ubuntu 16.04.1 LTS iso to the instance to boot from initially. Two NICs, first attached to bridge1. Second attached to bridge2.
Go through the installation procedure, logging in to the iscsi endpoint on 192.168.0.1, using the details above (no username/password necessary with this configuration) and install to the iSCSI target. At the end, detach the CD-ROM and ensure everything is set up to network boot.
On start-up you should see it network boot happily, everything is awesome. Do a "sudo apt update" and "sudo apt upgrade". Then reboot.
On start-up you should see the bug happening. ipconfig is sending out DHCP requests on both interfaces and failing to accept any responses it is being sent ("journalctl -xef -u dnsmasq" on primary shows it is sending them). If you remove that second NIC, you'll see that the instance is able to boot happily.