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
>> >
>>
>
