I don't see 06:47:4c:00:00:28 in there. I guess that's why you get an "ignore" from dnsmasq.
Not sure what is happening there. :) -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro ----- Original Message ----- > From: "Cristian Ciobanu" <cristian.c@istream.today> > To: users@cloudstack.apache.org > Sent: Sunday, 13 December, 2015 17:11:07 > Subject: Re: Cloudstack VR 4.6 issue > Yes, please see: > > root@r-58-VM:~# cat /etc/dhcphosts.txt > 06:f6:d0:00:00:28,158.xx.xxx.164,TEST3,infinite > 06:9f:04:00:00:0d,149.xxx.xx.163,TEST1,infinite > 06:01:4e:00:00:0b,149.xxx.xx.161,TEST2,infinite > > Regards, > Cristian > > > On 12/13/2015 7:08:52 PM, Nux! <n...@li.nux.ro> wrote: > Is there an entry for this MAC on the VR in /etc/dhcphosts.txt ? > > -- > Sent from the Delta quadrant using Borg technology! > > Nux! > www.nux.ro > > ----- Original Message ----- >> From: "Cristian Ciobanu" >> To: users@cloudstack.apache.org >> Sent: Sunday, 13 December, 2015 15:52:38 >> Subject: Re: Cloudstack VR 4.6 issue > >> I set back to dhcp, when the VM ask VR for IP, i see the following events on >> VR >> logs : >> >> >> ==> dnsmasq.log <==> >> Dec 13 15:50:29 dnsmasq-dhcp[9457]: DHCPDISCOVER(eth0) 06:47:4c:00:00:28 >> ignored >> Dec 13 15:50:31 dnsmasq-dhcp[9457]: DHCPDISCOVER(eth0) 06:47:4c:00:00:28 >> ignored >> Dec 13 15:50:38 dnsmasq-dhcp[9457]: DHCPDISCOVER(eth0) 06:47:4c:00:00:28 >> ignored >> >> >> Regards, >> Cristian >> >> On 12/13/2015 4:42:36 PM, Nux! wrote: >> Ok, this is weird, DHCP traffic should not be blocked anywhere. Also stop >> ebtables just in case and repeat, but if you remove the statically assigned >> IP >> and manually run "dhclient eth0", does it get an IP? What do the logs on the >> VR >> say? >> >> -- >> Sent from the Delta quadrant using Borg technology! >> >> Nux! >> www.nux.ro >> >> ----- Original Message ----- >>> From: "Cristian Ciobanu" >>> To: users@cloudstack.apache.org >>> Sent: Sunday, 13 December, 2015 14:36:35 >>> Subject: Re: Cloudstack VR 4.6 issue >> >>> Hi Lucian, >>> >>> Yes, the firewall is off. >>> >>> When i set the network from dhcp to static for VM TEST3 i was able to >>>ping the >>> gateway and google.com ( i used the same IP allocated to VM in >>>cloudstack from >>> that range) >>> >>> Thank you! >>> >>> >>> Regards, >>> Cristian >>> >>> >>> On 12/13/2015 1:42:05 PM, Nux! wrote: >>> Looks ok at the first sight? >>> Have you stopped iptables on the HV? >>> >>> If you manually set an IP from the range on TEST3, are you able to ping the >>> VR >>> IP or the TEST2 VM? >>> What is "arp -a" saying? >>> >>> -- >>> Sent from the Delta quadrant using Borg technology! >>> >>> Nux! >>> www.nux.ro >>> >>> ----- Original Message ----- >>>> From: "Cristian Ciobanu" >>>> To: users@cloudstack.apache.org >>>> Sent: Sunday, 13 December, 2015 10:49:10 >>>> Subject: Re: Cloudstack VR 4.6 issue >>> >>>> i forgot to add "brctl show" info in previous email. >>>> >>>> >>>> [root@hostxxx ~]# brctl show >>>> bridge name bridge id STP enabled interfaces >>>> cloud0 8000.fe00a9fe0089 no vnet0 >>>> vnet3 >>>> vnet7 >>>> cloudbr0 8000.000000000000 yes >>>> cloudbr1 8000.0cc47a6966cb no eth1 >>>> vnet1 >>>> vnet10 >>>> vnet2 >>>> vnet4 >>>> vnet5 >>>> vnet6 >>>> vnet8 >>>> vnet9 >>>> virbr0 8000.525400ac1c4a yes virbr0-nic >>>> >>>> >>>> Regards, >>>> Cristian >>>> >>>> >>>> On 12/13/2015 12:37:11 PM, Cristian Ciobanu wrote: >>>> Hi Lucian, >>>> >>>> Please see the requested information, also the VM are in the same >>>>bridge. >>>> >>>> VR XML : >>>> >>>> [root@host001 ~]# virsh dumpxml r-58-VM >>>> >>>> r-58-VM >>>> 1db38c1e-ea4d-4c3a-a401-263d10020de2 >>>> Debian GNU/Linux 5.0 (64-bit) >>>> 262144 >>>> 262144 >>>> 1 >>>> >>>> 500 >>>> >>>> >>>> >>>> Apache Software Foundation >>>> CloudStack KVM Hypervisor >>>> 1db38c1e-ea4d-4c3a-a401-263d10020de2 >>>> >>>> >>>> >>>> hvm >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> destroy >>>> restart >>>> destroy >>>> >>>> /usr/libexec/qemu-kvm >>>> >>>> >>>> >>>> >>>> >>>> >>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>>> >>>> >>>> >>>> >>> >>>> >>>> >>>> >>>> >>> >>>> >>>> >>>> >>>> >>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> TEST2 VM with connection : >>>> >>>> [root@host001 ~]# virsh dumpxml i-2-59-VM >>>> >>>> i-2-59-VM >>>> 4e95e133-4ce6-4954-aaf8-547cb77e5e7a >>>> CentOS 5.5 (64-bit) >>>> 524288 >>>> 524288 >>>> 1 >>>> >>>> 1000 >>>> >>>> >>>> >>>> Apache Software Foundation >>>> CloudStack KVM Hypervisor >>>> 4e95e133-4ce6-4954-aaf8-547cb77e5e7a >>>> >>>> >>>> >>>> hvm >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> destroy >>>> restart >>>> destroy >>>> >>>> /usr/libexec/qemu-kvm >>>> >>>> >>>> >>>> >>>> >>>> >>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>>> >>>> >>>> >>>> >>> >>>> >>>> >>>> >>>> >>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> TEST3 VM no connection : >>>> >>>> [root@host001 ~]# virsh dumpxml i-2-60-VM >>>> >>>> i-2-60-VM >>>> eadc00f4-bc9b-4b23-8874-a510eb8c021b >>>> CentOS 5.5 (64-bit) >>>> 524288 >>>> 524288 >>>> 1 >>>> >>>> 1000 >>>> >>>> >>>> >>>> Apache Software Foundation >>>> CloudStack KVM Hypervisor >>>> eadc00f4-bc9b-4b23-8874-a510eb8c021b >>>> >>>> >>>> >>>> hvm >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> destroy >>>> restart >>>> destroy >>>> >>>> /usr/libexec/qemu-kvm >>>> >>>> >>>> >>>> >>>> >>>> >>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>>> >>>> >>>> >>>> >>> >>>> >>>> >>>> >>>> >>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Regards, >>>> Cristian >>>> www.istream.today [http://www.istream.today/] >>>> www.shape.host [http://www.shape.host/] >>>> +40.733.955.922 >>>> >>>> On 12/12/2015 11:14:23 PM, Nux! wrote: >>>> Cristian, >>>> >>>> This is weird. On the HV can you check "brctl show" both the VR interface >>>> as >>>> well as the VMs in the same bridge? >>>> You can get their vnets by way of "virsh dumpxml name". >>>> Also, before you repeat any tests, please disable iptables on the HV >>>> (service >>>> iptables stop). >>>> >>>> Lucian >>>> >>>> -- >>>> Sent from the Delta quadrant using Borg technology! >>>> >>>> Nux! >>>> www.nux.ro >>>> >>>> ----- Original Message ----- >>>>> From: "Cristian Ciobanu" >>>>> To: users@cloudstack.apache.org >>>>> Sent: Saturday, 12 December, 2015 16:44:19 >>>>> Subject: Re: Cloudstack VR 4.6 issue >>>> >>>>> Hi Lucian, >>>>> >>>>> I did what you told me, I also find something interesting on VR >>>>>dnsmasq log, >>>>> please see the screenshot and the syslog from this mail. >>>>> >>>>> You will see the VR show MAC address ignored for TEST3, i'm not sure >>>>>why. >>>>> >>>>> Screenshots : http://imgur.com/a/HHYUr >>>>> >>>>> Syslog: >>>>> >>>>> Nov 9 11:20:03 systemvm kernel: [ 187.084419] RPC: Registered named UNIX >>>>> socket transport module. >>>>> Nov 9 11:20:03 systemvm kernel: [ 187.084419] RPC: Registered udp >>>>> transport >>>>> module. >>>>> Nov 9 11:20:03 systemvm kernel: [ 187.084419] RPC: Registered tcp >>>>> transport >>>>> module. >>>>> Nov 9 11:20:03 systemvm kernel: [ 187.084419] RPC: Registered tcp >>>>> NFSv4.1 >>>>> backchannel transport module. >>>>> Nov 9 11:20:03 systemvm kernel: [ 187.111188] FS-Cache: Loaded >>>>> Nov 9 11:20:03 systemvm kernel: [ 187.134041] FS-Cache: Netfs 'nfs' >>>>> registered >>>>> for caching >>>>> Nov 9 11:20:03 systemvm kernel: [ 187.163769] Installing knfsd >>>>> (copyright (C) >>>>> 1996 o...@monad.swb.de). >>>>> Nov 9 11:20:08 systemvm kernel: [ 192.071255] Netfilter messages via >>>>> NETLINK >>>>> v0.30. >>>>> Nov 9 11:20:08 systemvm kernel: [ 192.079893] nf_conntrack version >>>>> 0.5.0 (1959 >>>>> buckets, 7836 max) >>>>> Nov 9 11:20:08 systemvm conntrack-tools[11427]: using user-space event >>>>> filtering >>>>> Nov 9 11:20:08 systemvm conntrack-tools[11427]: netlink event socket >>>>> buffer >>>>> size has been set to 262142 bytes >>>>> Nov 9 11:20:08 systemvm conntrack-tools[11427]: initialization completed >>>>> Nov 9 11:20:08 systemvm conntrack-tools[11432]: -- starting in daemon >>>>> mode -- >>>>> Nov 9 11:20:08 systemvm kernel: [ 192.081523] ctnetlink v0.93: >>>>> registering >>>>> with nfnetlink. >>>>> Nov 9 11:20:08 systemvm dnsmasq[11500]: started, version 2.62 cachesize >>>>> 150 >>>>> Nov 9 11:20:08 systemvm dnsmasq[11500]: compile time options: IPv6 >>>>> GNU-getopt >>>>> DBus i18n IDN DHCP DHCPv6 no-Lua TFTP conntrack >>>>> Nov 9 11:20:08 systemvm dnsmasq[11500]: reading /etc/resolv.conf >>>>> Nov 9 11:20:08 systemvm dnsmasq[11500]: using nameserver 8.8.4.4#53 >>>>> Nov 9 11:20:08 systemvm dnsmasq[11500]: using nameserver 8.8.8.8#53 >>>>> Nov 9 11:20:08 systemvm dnsmasq[11500]: read /etc/hosts - 4 addresses >>>>> Nov 9 11:20:09 systemvm kernel: [ 193.428232] ip_tables: (C) 2000-2006 >>>>> Netfilter Core Team >>>>> Nov 9 11:20:09 systemvm kernel: [ 193.447974] ip6_tables: (C) 2000-2006 >>>>> Netfilter Core Team >>>>> Nov 9 11:20:13 systemvm xl2tpd[11917]: setsockopt recvref[30]: Protocol >>>>> not >>>>> available >>>>> Nov 9 11:20:13 systemvm xl2tpd[11917]: This binary does not support >>>>> kernel >>>>> L2TP. >>>>> Nov 9 11:20:13 systemvm xl2tpd[11918]: xl2tpd version xl2tpd-1.3.1 >>>>> started on >>>>> systemvm PID:11918 >>>>> Nov 9 11:20:13 systemvm xl2tpd[11918]: Written by Mark Spencer, >>>>> Copyright (C) >>>>> 1998, Adtran, Inc. >>>>> Nov 9 11:20:13 systemvm xl2tpd[11918]: Forked by Scott Balmos and David >>>>> Stipp, >>>>> (C) 2001 >>>>> Nov 9 11:20:13 systemvm xl2tpd[11918]: Inherited by Jeff McAdams, (C) >>>>> 2002 >>>>> Nov 9 11:20:13 systemvm xl2tpd[11918]: Forked again by Xelerance >>>>> (www.xelerance.com) (C) 2006 >>>>> Nov 9 11:20:13 systemvm xl2tpd[11918]: Listening on IP address 0.0.0.0, >>>>> port >>>>> 1701 >>>>> Nov 9 11:20:42 systemvm /usr/sbin/irqbalance: Balancing is ineffective on >>>>> systems with a single cache domain. Shutting down >>>>> Nov 9 11:20:59 systemvm KVP: KVP starting; pid is:18270 >>>>> Nov 9 11:21:36 systemvm shutdown[21010]: shutting down for system halt >>>>> Nov 9 11:21:36 systemvm init: Switching to runlevel: 0 >>>>> Nov 9 11:21:37 systemvm KVP: KVP starting; pid is:21036 >>>>> Nov 9 11:21:37 systemvm KVP: recvfrom failed; pid:21036 error:2 No such >>>>> file or >>>>> directory >>>>> Nov 9 11:21:37 systemvm init: Re-reading inittab >>>>> Nov 9 11:21:37 systemvm conntrack-tools[11432]: ---- shutdown received >>>>> ---- >>>>> Nov 9 11:21:39 systemvm dnsmasq[11500]: exiting on receipt of SIGTERM >>>>> Nov 9 11:21:39 systemvm acpid: exiting >>>>> Nov 9 11:21:39 systemvm xl2tpd[11918]: death_handler: Fatal signal 15 >>>>> received >>>>> Nov 9 11:21:39 systemvm ntpd[1732]: ntpd exiting on signal 15 >>>>> >>>>> >>>>> >>>>> >>>>> Multumesc ! >>>>> >>>>> >>>>> Regards, >>>>> Cristian >>>>> >>>>> >>>>> On 12/12/2015 1:38:43 PM, Nux! wrote: >>>>> Cristian, >>>>> >>>>> So adding the IPs is not a problem, I see a few subnets added there. >>>>> >>>>> I see TEST3 should have got an IP address ending in 165, but has not. >>>>> Can you check /var/log/messages (/var/log/syslog) on the VM and the VR, >>>>> see if >>>>> you see anything regarding DHCP, the VM's MAC address and so on. >>>>> Also, if you restart the network on the VM or simply run `dhclient eth0`, >>>>> do you >>>>> get an IP? >>>>> >>>>> Lucian >>>>> >>>>> -- >>>>> Sent from the Delta quadrant using Borg technology! >>>>> >>>>> Nux! >>>>> www.nux.ro >>>>> >>>>> ----- Original Message ----- >>>>>> From: "Cristian Ciobanu" >>>>>> To: users@cloudstack.apache.org >>>>>> Sent: Friday, 11 December, 2015 21:23:12 >>>>>> Subject: Re: Cloudstack VR 4.6 issue >>>>> >>>>>> I removed the URL and i did a re-upload of the screenshots because i >>>>>> forgot to >>>>>> hide some IP. ( also one of the server was compromised ) >>>>>> >>>>>> >>>>>> NEW URL: http://imgur.com/a/0qmvx >>>>>> >>>>>> >>>>>> Regards, >>>>>> Cristian >>>>>> www.istream.today [http://www.istream.today/] >>>>>> www.shape.host [http://www.shape.host/] >>>>>> +40.733.955.922 >>>>>> >>>>>> On 12/11/2015 7:09:57 PM, Cristian Ciobanu wrote: >>>>>> Please see the screenshots from following URL: http://imgur.com/a/Fbbyi >>>>>> >>>>>> Thank you. >>>>>> >>>>>> >>>>>> Regards, >>>>>> Cristian >>>>>> >>>>>> >>>>>> On 12/11/2015 5:38:30 PM, Nux! wrote: >>>>>> Cristian, >>>>>> >>>>>> The mailing list seems to be stripping attachments, you might want to >>>>>> upload the >>>>>> pictures somewhere on the web and share the link. >>>>>> >>>>>> I tried adding a bogus new subnet to my existing 4.6 testbed and it >>>>>> worked >>>>>> without problems, I could give instances IP from it. >>>>>> >>>>>> You might want to go through the management logs (don't forget to enable >>>>>> DEBUG) >>>>>> while you are trying to use the new IPs on the instance. >>>>>> >>>>>> -- >>>>>> Sent from the Delta quadrant using Borg technology! >>>>>> >>>>>> Nux! >>>>>> www.nux.ro >>>>>> >>>>>> ----- Original Message ----- >>>>>>> From: "Cristian Ciobanu" >>>>>>> To: users@cloudstack.apache.org >>>>>>> Sent: Friday, 11 December, 2015 13:40:26 >>>>>>> Subject: Re: Cloudstack VR 4.6 issue >>>>>> >>>>>>> First of all, thanks for the answer. >>>>>>> >>>>>>> This is how i did, was work before on CloudStack 4.5 I'm not sure if >>>>>>> this is a >>>>>>> 4.6 issue or i did something wrong. >>>>>>> >>>>>>> Please see the attached screenshots. >>>>>>> >>>>>>> If you see on VR.jpg the class starting with 149. works great but 158. >>>>>>> not. also >>>>>>> the if you see the screenshot for VM TST2, everything is fine, but for >>>>>>> VM TST3 >>>>>>> not, no IP was allocated on VM. >>>>>>> >>>>>>> Thank you! >>>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> Cristian >>>>>>> >>>>>>> >>>>>>> On 12/11/2015 3:07:34 PM, Nux! wrote: >>>>>>> Cristian, >>>>>>> >>>>>>> In a Basic Network you only have one public interface on the VR, as >>>>>>> well as >>>>>>> 169.254 on eth1 - that's a link-local address used to communicate with >>>>>>> the HV. >>>>>>> - >>>>>>> To add a new subnet to your network you must go to Home - >>>>>>> Infrastructure - Zones >>>>>>> - Your Zone - Physical Network - Your Public Network - Guest - Network >>>>>>> - click >>>>>>> existing network - View IP Ranges - Add IP Range ... (it's actually >>>>>>> simpler >>>>>>> from the API/cloudmonkey). >>>>>>> >>>>>>> Once you have added it your VR should start using it at some point, >>>>>>> especially >>>>>>> if you have exhausted your current subnet. >>>>>>> You can check what IP it passed out to instances in /etc/dhcphosts.txt >>>>>>> >>>>>>> HTH >>>>>>> >>>>>>> -- >>>>>>> Sent from the Delta quadrant using Borg technology! >>>>>>> >>>>>>> Nux! >>>>>>> www.nux.ro >>>>>>> >>>>>>> ----- Original Message ----- >>>>>>>> From: "Cristian Ciobanu" >>>>>>>> To: users@cloudstack.apache.org >>>>>>>> Sent: Friday, 11 December, 2015 12:17:23 >>>>>>>> Subject: Cloudstack VR 4.6 issue >>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> I try to find the issue regarding additional IP class. >>>>>>>> >>>>>>>> I have a CloudStack 4.6 on CentOS 6.7 ( 1x MGMT server and one KVM >>>>>>>>host with >>>>>>>> basic network ) >>>>>>>> >>>>>>>> Everything works fine till i try to add a additional guest IP class >>>>>>>>the >>>>>>>> additional is not working also i don't see any changes on VR and I >>>>>>>>have only 1 >>>>>>>> NIC with GUEST traffic on the VR, does not matter if i add 1,2,3 >>>>>>>>etc.. guest IP >>>>>>>> class i don't see any updates on my VR also if i create a new VM >>>>>>>>the IP looks >>>>>>>> like is allocated in CloudStack web interface but no IP allocated >>>>>>>>on the VM >>>>>>>> side. >>>>>>>> >>>>>>>> Can i get some help regarding this ? >>>>>>>> >>>>>>>> >>>>>>>> Regards, > > > > > > > > Cristian
