On 07/11/2016 20:52, Brian Candler wrote:
So either this means that using tap networking instead of user
networking is fixing all the problems; or it is some other option
which is different. Really I now need to run qemu with exactly the
same settings as before, except with tap instead of user networking.
I hacked something together to run qemu directly with the right flags
for tap networking.
packer.io now connects via ssh to the IP address which the DHCP server
gives out for that MAC address, and runs the same provisioning code as
before (actually a whole load of ansible scripts)
I ran it three times successfully from start to end, with no crashes.
Hence it does appear likely then that the crashes are something to do
with the user networking.
Regards,
Brian.
#!/bin/sh -e
cp output-qemu-ubuntu-base/ubuntu-base.qcow2
output-null-vtp-nmm/vtp-nmm.qcow2
TAP=tap0
sudo tunctl -d tap0
sudo tunctl -u $(whoami)
sudo brctl addif br-lan $TAP
sudo ip link set dev $TAP up
echo "Starting kvm..."
/usr/local/bin/qemu-system-x86_64 \
-machine type=pc,accel=kvm \
-device virtio-scsi-pci,id=scsi0 \
-device scsi-hd,bus=scsi0.0,drive=drive0 \
-device virtio-net,netdev=network0,id=net0,mac=52:54:00:cc:c1:62 \
-vnc [::]:24 \
-name vtp-nmm.qcow2 \
-boot c \
-netdev tap,id=network0,ifname=$TAP,script=no,downscript=no \
-drive
if=none,file=output-null-vtp-nmm/vtp-nmm.qcow2,id=drive0,cache=writeback,discard=unmap,format=qcow2
\
-m 4G
# waiting for exit
sudo tunctl -d tap0