So if I understand your mail correctly, a VpcDnsMasqConfigurator should be created to be used in configDnsMasq in VpcVirtualApplienceManagerImpl, instead of the one used now?
On Sun, Jul 21, 2013 at 6:01 PM, Sheng Yang <sh...@yasker.org> wrote: > Hi Daan, > > We're talking about vpc router. Your patch affect the guest vm because > guest VM cannot get ip address from VPC router(DHCP request fail). > > The VPC indeed using a different dnsmasq.conf. See > /etc/vpcdnsmasq.conf(which is a template of VPC used dnsmasq). > > You're using DnsMasqConfigurator, which is only used for normal VR before > your patch. It would generated dnsmasq.conf contained: > > <quote> > except-interface=eth1 > except-interface=eth2 > except-interface=lo > </quote> > > However, these lines by no chance can work in a VPC router, which is > introduced by your commit. Because for VPC router, eth2 is the first guest > nic, it cannot be excepted from listening ports, otherwise any guest vm's > dhcp request in the first subnet would fail to get IP address through DHCP. > > --Sheng > > > On Sun, Jul 21, 2013 at 3:49 AM, Daan Hoogland <daan.hoogl...@gmail.com > >wrote: > > > H Sheng et al, > > > > I have no overview of what effect my patch has on guest vm's. It is > > supposed to only generate a dnsmasq.conf for vpc-router-vm's. not > > guestnetwork-vm's. I am happy to look at it, but have no overview of the > > issue yet. Should a sepperate dnsmasq.conf instance be created for vpc > > routers to deal with the different nics? > > > > > > On Sat, Jul 20, 2013 at 3:32 AM, Sheng Yang <sh...@yasker.org> wrote: > > > > > Daan, I've checked the code, the issue is, original code Bharat > > > wrote(generated dnsmasq.conf) cannot deal with VPC. e.g. the VPC router > > > wouldn't listen on eth0 and eth1, but non-vpc router wouldn't listen on > > > eth1 and eth2. Also, some detail configurations of VPC are written into > > > /etc/dnsmasq.d/cloud.conf, rather than dnsmasq.conf, because it need to > > > deal with multiple nics with different range. > > > > > > So using non-vpc's configuration just break whole VPC function. No > chance > > > it can work because eth2(which is internal network interface in VPC) is > > > excluded from listening interface. > > > > > > We need to deal with it ASAP because it's blocking the regression test. > > In > > > fact I didn't see much solution for now except reverting it since the > > > dnsmasq config command didn't support VPC anyway. > > > > > > BTW, I don't agree that we need dnsmasq configuration file generated by > > > cloudstack, since it's possible that the scripts in the VR would modify > > the > > > file as well(e.g. in cloud-early-setup), then the modification would be > > > overrided by whole new file generated by management server(which > happened > > > in this case). We have to gather them in one place. I've talked with > > Bharat > > > and he would provide a patch soon to revert the DnsMasqConfigurator, > and > > > use bash scripts to do the necessary substitute instead. I think any > > > potential change to dnsmasq config command need to wait for it. > > > > > > --Sheng > > > > > > > > > On Fri, Jul 19, 2013 at 5:54 PM, Sheng Yang <sh...@yasker.org> wrote: > > > > > > > Daan, > > > > > > > > Bharat thinks your fix caused a block bug > > > > https://issues.apache.org/jira/browse/CLOUDSTACK-3589? Could you > check > > > it? > > > > > > > > --Sheng > > > > > > > > On Thu, Jul 18, 2013 at 9:52 AM, Bharat Kumar < > bharat.ku...@citrix.com > > > >wrote: > > > > > > > >> Hi Dann, > > > >> > > > >> The bug fix > > > >> > > > > > > https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commitdiff;h=b903262df5e2ff5d174859ce28abae75c4689f0cis > > > >> causing an null value in dnsmasq.config file while creating VPC > > network > > > >> (bug-id Cloudstack-3589 ). > > > >> > > > >> Can you please take a look at this. > > > >> > > > >> Regards, > > > >> Bharat. > > > > > > > > > > > > > > > > > >
