No way to manually restrict DHCP to one interface

[Phil Pemberton]

This is more a feature request than an actual bug.

When Orchestra installs and Cobbler is first configured with a server, it defaults to listening on the first available network interface (usually eth0) for DHCP requests.

This causes problems when Orchestra is used to bring up a cluster of virtual machines running on one physical server -- the virtual machines send DHCP requests over a host-only interface, but dnsmasq (the DNS/DHCP server Orchestra uses) never sees them. This leaves the VMs stuck waiting for DHCP data which will never arrive...

The solution is twofold:
  - Initially, use Virt-Manager or similar to create a virtual network for all the virtual machines which are to be managed by Orchestra. Call it, for example "PxeReload". Virt-Manager will tell you what the physical network device name is -- in my case, it was virbr1. Set this as active, autostarting on boot, with DHCP disabled and the IP range you desire (I used 192.168.100.0/24). Forwarding should be set to "Isolated Network" (otherwise it will stomp all over your LAN's DHCP server)

  - Install orchestra-server. Provide details about your network. In my case, I used:
    Password for cobbler user -- (like I'd tell you that!)
    Boot and PXE server IP -- was autodetected OK, but in my case, 192.168.100.1
    Enable Orchestra Managed DHCP/DNS? Yes
    DHCP Range: 192.168.100.5,192.168.100.200
    Default Gateway for DHCP clients: leave blank (it's the Provisioning server)
    Domain name: virtual.lan (I just used virtual)

Once you've done this, you can follow the instructions in http://cloud.ubuntu.com/2011/09/oneiric-server-deploy-server-fleets-p2/ and/or http://cloud.ubuntu.com/2011/10/getting-started-with-ubuntu-orchestra-servers-in-concert/ to add the virtual machine (created with virt-manager, VirtualBox, VMware or whatever) to Cobbler.

Now you need to edit Cobbler's DNSMasq config template --
  - sudo vim /etc/cobbler/dnsmasq.template

After "domain=virtual", insert these lines:

# Restrict DNSMasq DHCP and DNS to host-only virtual Ethernet bridge used for PXE reloads
interface = virbr1

Save and exit.

Run "sudo cobbler sync" and everything should work. If DNSMasq fails to restart, "sudo killall dnsmasq" then "sudo service dnsmasq restart" (sometimes the rcscript thinks DNSMasq is stopped when in fact it is still running).

After all this, you should have a server, hosting virtual machines which you can create, configure, set up, tear down and reinstall to your heart's content.

[Phil Pemberton (philpem)]

I forgot something -- after "interface = (virbr1, br0, or whatever)" you need to add:
  bind-interfaces
Otherwise dnsmasq will still bind to all interfaces instead of just the assigned interface.

Another thing worth mentioning is that virt-manager / libvirt uses dnsmasq internally. It gets VERY upset if you try and run Cobbler on a bridged interface. What you need to do is create a bridge with no assigned interfaces in /etc/network/interfaces (I called mine 'vmpxe' -- Virtual Machine PXE), give it an IP address and so forth, and attach Orchestra's dnsmasq instance to that interface. Then when you create the VM, attach the network adapter to that interface (i.e. "specify shared device name", then the name of the bridge)

[Sasa Paporovic (melchiaros)]

@ andreserl

I am unhappy with the importance. This here and especially for me is not a wish, becaus I hang on :

Another thing worth mentioning is that virt-manager / libvirt uses dnsmasq internally. It gets VERY upset if you try and run Cobbler on a bridged interface. What you need to do is create a bridge with no assigned interfaces in /etc/network/interfaces (I called mine 'vmpxe' -- Virtual Machine PXE), give it an IP address and so forth, and attach Orchestra's dnsmasq instance to that interface. Then when you create the VM, attach the network adapter to that interface (i.e. "specify shared device name", then the name of the bridge)

------------------------------------------------------

So this here is as far as I am affected a bug - and not a little one -, because it breaks my virtualmachine settup completely.

No access to any vm with virt-manager/libvirt anymore -> This is a problem!