Seeking support for using qm create and specifying a bridge

TJ Zimmerman

Active Member
Apr 8, 2018
8
0
41
31
Seattle
tjzimmerman.com
Hello Proxmox team, I have been trying to provision a VM to use a network bridge all evening unsucessfully.

The following commands create a working VM that is configured via cloud-init. This works great and the VM starts up just fine. However, the `/etc/resolv.conf` file contains a nameserver entry for `10.0.2.3`. I understand this information is injected when a NAT interface is configured because a Bridge interface is not specified. However, if you look in the `--net0` part of the `qm create` command, you can see that I am, in fact, specifying a Bridge interface. Do I have the syntax wrong?

Code:
qm create 170 --cores 2 --memory 4096 --net0 "virtio,bridge=vmbr0" --ipconfig0 "gw=192.168.1.1,ip=192.168.1.170/24" --nameserver 192.168.1.10 --searchdomain "sol.milkyway" --sshkeys /root/.ssh/sol.milkyway.kubernetes.pub

#URL has been removed from this command since I am a new user and unable to post them.
wget CentOS-7-x86_64-GenericCloud.qcow2c -O /tmp/CentOS7.qcow2c

qm importdisk 170 /tmp/CentOS7.qcow2c Proxmox_lvm-thin

qm set 170 --scsihw virtio-scsi-pci --scsi0 Proxmox_lvm-thin:vm-170-disk-0

qm resize 170 scsi0 50G

qm set 170 --ide2 Proxmox_lvm-thin:cloudinit

qm set 170 --boot c --bootdisk scsi0

qm start 170

I know this seems like a minor issue. But I'm doing this all through Ansible. And since SSHD sets the `UseDNS` directive to `yes` by default, this means that Ansible times out when attempting to connect the first time because a reverse DNS lookup fails due to `10.0.2.3` not being a valid nameserver on my network.

[centos@VM170 ~]$ cat /etc/resolv.conf
; Created by cloud-init on instance boot automatically, do not edit.
;
# Generated by NetworkManager
nameserver 10.0.2.3
nameserver 192.168.1.10
search sol.milkyway

Thank you for your time.
 
If you search Server Fault for the post titled:

Ansible fails at “Gathering hosts” presumably because SSH is slow to connect. Setting `UseDNS no` resolves the issue

You'll be able see a few hours worth of troubleshooting that I performed before coming to this conclusion. If you need additional context on the issue.
 
# Generated by NetworkManager
this is under control by cloudinit/network manager, there is not much we can do beside give cloudinit those informations
try to use a newer cloudinit version, since most versions shipped in the distros are broken in various ways