Jesse: As Andrija said, this is a purely DHCP issue, has nothing to do with the CloudStack.
We have a similar set up here , where both ACS VM instances and non-ACS servers exist on the same subnet, and they are served by separated DHCP servers (stock ISC dhcp server on RHEL). Here is how we solved the conflict. For non-ACS DHCP server, In dhcpd.conf, we define a class for Cloudstack instances based on their MAC address. Then in the pool stanza for each subnet served by this (non ACS) DHCP server , just ignore members of cloustack class. Here are the relevant snippets in dhcpd.conf: class "Cloudstack" { match if substring(hardware,1,1) = 06; } ... # Prod_DMZ_subnet subnet 10.0.8.0 netmask 255.255.252.0 { pool { deny members of "Cloudstack"; ... } ... } In earlier versions of ACS, all VM's MAC address start with "06:". I think in current version of ACS, they start with "1e:" now. Hope this helps. Yiping On 7/9/19, 9:44 AM, "jesse.wat...@gmail.com" <jesse.wat...@gmail.com> wrote: Interesting proxy in to vm pkill dhclient dhclient -x dhclient eth0 get ip I expected, odd On Tue, Jul 9, 2019 at 11:16 AM <jesse.wat...@gmail.com> wrote: > > My vm was assigned an ip from our endpoint DHCP server, not from VR. Do I > need to add firewall rule(s) to force DHCP request to VR? I probably missed > a part of setup w/KVM hosts and or within management when I defined the > zone/pod/... > > This seems to be correct, VR is running on a different host then the vm. > > Chain i-2-11-VM-eg (1 references) > pkts bytes target prot opt in out source > destination > 0 0 RETURN all -- * * 0.0.0.0/0 > 0.0.0.0/0 > > Chain i-2-11-def (2 references) > pkts bytes target prot opt in out source > destination > 0 0 ACCEPT all -- * * 0.0.0.0/0 > 0.0.0.0/0 state RELATED,ESTABLISHED > 0 0 ACCEPT udp -- * * 0.0.0.0/0 > 0.0.0.0/0 PHYSDEV match --physdev-in vnet0 > --physdev-is-bridged udp spt:68 dpt:67 > 0 0 ACCEPT udp -- * * 0.0.0.0/0 > 0.0.0.0/0 PHYSDEV match --physdev-out vnet0 > --physdev-is-bridged udp spt:67 dpt:68 > 0 0 DROP all -- * * 0.0.0.0/0 > 0.0.0.0/0 PHYSDEV match --physdev-in vnet0 > --physdev-is-bridged ! match-set i-2-11-VM src > 0 0 RETURN udp -- * * 0.0.0.0/0 > 0.0.0.0/0 PHYSDEV match --physdev-in vnet0 > --physdev-is-bridged match-set i-2-11-VM src udp dpt:53 > 0 0 RETURN tcp -- * * 0.0.0.0/0 > 0.0.0.0/0 PHYSDEV match --physdev-in vnet0 > --physdev-is-bridged match-set i-2-11-VM src tcp dpt:53 > 0 0 i-2-11-VM-eg all -- * * 0.0.0.0/0 > 0.0.0.0/0 PHYSDEV match --physdev-in vnet0 > --physdev-is-bridged match-set i-2-11-VM src > 15 1963 i-2-11-VM all -- * * 0.0.0.0/0 > 0.0.0.0/0 PHYSDEV match --physdev-out vnet0 > --physdev-is-bridged > > > > Thanks for quick response Andrija! > > - Jesse > > > > > On Tue, Jul 9, 2019 at 10:39 AM Andrija Panic <andrija.pa...@gmail.com> > wrote: > >> ACS will only offer DHCP leases to its VMs, via DHCP reservation.. If you >> have another DHCP server in your area, than it might be quicker to offer a >> lease to a VM. You have to either remove your non-ACS DHCP server >> completely, OR make sure it uses reservation for non-ACS servers/hosts >> i.e. >> NOT let it issue leases freely to anyone who asks for it. Pure DHCP >> "problem" - i.e. nothing to do with ACS specifically. >> >> Best, >> Andrija >> >> On Tue, Jul 9, 2019, 20:27 <jesse.wat...@gmail.com> wrote: >> >> > Have a DHCP issue where vm pulls from ACS proxy properly sometimes and >> > other when it pulls from our normal dhcp server for end-points. >> > >> > Network layout is flat, and I ACS is using basic network with security >> > groups. IP range for acs is within range of our normal network so vms >> and >> > endpoints will flow without additional hardware. How do I ensure dhcp >> > requests are served by router vm and not our normal dhcp server? >> > >> > TIA, >> > Jesse >> > >> >