Re: Cloudstack 4.3 instances can't access outside world
Hi Seresh, This bug is still unassigned. It will be fixed? Currently is now way for upgrade to 4.3, 4.4.. On Mon, Apr 21, 2014 at 11:46 AM, Suresh Sadhu suresh.sa...@citrix.comwrote: This need to be addressed and for tracking purpose I have raised this bug. kindly update your findings: https://issues.apache.org/jira/browse/CLOUDSTACK-6464 regards sadhu -Original Message- From: Serg [mailto:kernc...@gmail.com] Sent: 21 April 2014 12:04 To: users@cloudstack.apache.org Cc: users@cloudstack.apache.org Subject: Re: Cloudstack 4.3 instances can't access outside world Hi Suresh, Thanks for your update. There is already submitted bug ( bug id?)? it's will be fixed in 4.3.1 or committed to 4.4? -- Serg On 21 באפר 2014, at 08:50, Suresh Sadhu suresh.sa...@citrix.com wrote: Its temporary and its regression bug caused due to other last min commit. due to this traffic labels are not considering. Regards Sadhu -Original Message- From: Serg Senko [mailto:kernc...@gmail.com] Sent: 21 April 2014 11:12 To: users@cloudstack.apache.org Subject: Re: Cloudstack 4.3 instances can't access outside world Hi, What does mean In 4.3 traffic labels are not considering ? It's temporary or traffic labels is deprecated now ? Does mean, anyone with KVM traffic labels environment can't upgrade to 4.3.0? On Thu, Apr 10, 2014 at 5:05 PM, Suresh Sadhu suresh.sa...@citrix.com wrote: Did you used traffic name labels? In 4.3 traffic labels are not considering ,by default its attaching to default traffic labels(eg:in KVM its cloudbr0 ...due to this unable to access public network i.r before upgrade if ieth2 attached cloudbr1 and after upgrade its attached to cloudbr0).maybe you are hitting this issue. Regards sadhu -Original Message- From: motty cruz [mailto:motty.c...@gmail.com] Sent: 10 April 2014 19:28 To: users@cloudstack.apache.org Subject: Re: Cloudstack 4.3 instances can't access outside world yes I can ping VR, also after the upgrade VR has four insterfaces, eth0 subnet for Instances, eth1, eth2 for public IP and eth3 for public IP. On Wed, Apr 9, 2014 at 10:35 PM, Erik Weber terbol...@gmail.com wrote: Can you ping the VR? Log on to the VR, and get the iptables rules. How do they look? Erik Weber 10. apr. 2014 00:21 skrev motty cruz motty.c...@gmail.com følgende: I did add egress rules, reboot network but no sucess, so I removed that rules and nothing. I am lost. On Wed, Apr 9, 2014 at 9:08 AM, Erik Weber terbol...@gmail.com wrote: Did you remove the egress rule again? If not, try that. Erik 9. apr. 2014 15:49 skrev motty cruz motty.c...@gmail.com følgende: yes I try adding the rule, restart network and router but no success! On Tue, Apr 8, 2014 at 11:16 PM, Erik Weber terbol...@gmail.com wrote: Try adding an egress rule, and removing it again. We experience the same, but has so far believed it was because we changed the default rule from deny to allow after accounts were made.. On Tue, Apr 8, 2014 at 11:14 PM, motty cruz motty.c...@gmail.com wrote: I have two isolated network both virtual routers can ping anywhere, but the Instances behind the virtual router can't ping or access the internet. On Tue, Apr 8, 2014 at 10:38 AM, motty cruz motty.c...@gmail.com wrote: Hello, I'm having issues with VMs unable to access outside world. I can ping gateway, also when I log in to virtual router, I am able to ping google.com or anywhere. in the Egress rules I am allowing all. reboot network and virtual router does not help. VMs were able to access outside before upgrading from 4.2 to 4.3. any ideas? -- ttyv0 /usr/libexec/gmail Pc webcons on secure -- ttyv0 /usr/libexec/gmail Pc webcons on secure
Re: Cloudstack 4.3 instances can't access outside world
Hello all, There is some bug after upgrade from 4.1.1 to 4.3.0 KVM Hypervizor Agent settings labels : guest.network.device=cloudbr1 private.network.device=cloudbr1 public.network.device=cloudbr0 After upgrade to 4.3 SSVM, all VR's started with multiple [public] interfaces, I have some VR's with 5-6 ethX interfaces with same IP So, in all cases egress rules doesn't work. Fix? Workaround? On Sat, Apr 12, 2014 at 12:16 AM, motty cruz motty.c...@gmail.com wrote: I have a testing cloudstack cluster, I destroyed it and rebuilding upgraded serveral times, each time I ran into the same problem, unable to access outside world from instances behind virtual router. here is iptables before upgrade, Cloudstack 4.2 # Generated by iptables-save v1.4.14 on Fri Apr 11 19:53:57 2014 *mangle :PREROUTING ACCEPT [2317:1282555] :INPUT ACCEPT [409:147015] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [189:29312] :POSTROUTING ACCEPT [189:29312] :FIREWALL_176.23.23.192 - [0:0] :VPN_176.23.23.192 - [0:0] -A PREROUTING -d 176.23.23.192/32 -j VPN_176.23.23.192 -A PREROUTING -d 176.23.23.192/32 -j FIREWALL_176.23.23.192 -A PREROUTING -m state --state RELATED,ESTABLISHED -j CONNMARK --restore-mark --nfmask 0x --ctmask 0x -A POSTROUTING -p udp -m udp --dport 68 -j CHECKSUM --checksum-fill -A FIREWALL_176.23.23.192 -m state --state RELATED,ESTABLISHED -j ACCEPT -A FIREWALL_176.23.23.192 -j DROP -A VPN_176.23.23.192 -m state --state RELATED,ESTABLISHED -j ACCEPT -A VPN_176.23.23.192 -j RETURN COMMIT # Completed on Fri Apr 11 19:53:57 2014 # Generated by iptables-save v1.4.14 on Fri Apr 11 19:53:57 2014 *filter :INPUT DROP [204:117504] :FORWARD DROP [0:0] :OUTPUT ACCEPT [150:22404] :FW_OUTBOUND - [0:0] :NETWORK_STATS - [0:0] -A INPUT -j NETWORK_STATS -A INPUT -d 224.0.0.18/32 -j ACCEPT -A INPUT -d 225.0.0.50/32 -j ACCEPT -A INPUT -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -i eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -i eth2 -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -p icmp -j ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -i eth0 -p udp -m udp --dport 67 -j ACCEPT -A INPUT -i eth0 -p udp -m udp --dport 53 -j ACCEPT -A INPUT -i eth0 -p tcp -m tcp --dport 53 -j ACCEPT -A INPUT -i eth1 -p tcp -m state --state NEW -m tcp --dport 3922 -j ACCEPT -A INPUT -i eth0 -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT -A INPUT -s 10.1.1.0/24 -i eth0 -p tcp -m state --state NEW -m tcp --dport 8080 -j ACCEPT -A FORWARD -j NETWORK_STATS -A FORWARD -i eth0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT -A FORWARD -i eth0 -o eth0 -m state --state NEW -j ACCEPT -A FORWARD -i eth0 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT -A FORWARD -i eth2 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT -A FORWARD -i eth0 -o eth2 -j FW_OUTBOUND -A OUTPUT -j NETWORK_STATS -A FW_OUTBOUND -m state --state RELATED,ESTABLISHED -j ACCEPT -A NETWORK_STATS -i eth0 -o eth2 -A NETWORK_STATS -i eth2 -o eth0 -A NETWORK_STATS ! -i eth0 -o eth2 -p tcp -A NETWORK_STATS -i eth2 ! -o eth0 -p tcp COMMIT # Completed on Fri Apr 11 19:53:57 2014 # Generated by iptables-save v1.4.14 on Fri Apr 11 19:53:57 2014 *nat :PREROUTING ACCEPT [2078:1204416] :INPUT ACCEPT [10:964] :OUTPUT ACCEPT [1:338] :POSTROUTING ACCEPT [1:338] -A POSTROUTING -o eth2 -j SNAT --to-source 176.23.23.192 COMMIT # Completed on Fri Apr 11 19:53:57 2014 after upgrading to Cloudstack 4.3 :POSTROUTING ACCEPT [211:25828] :FIREWALL_176.23.23.192 - [0:0] :VPN_176.23.23.192 - [0:0] -A PREROUTING -d 176.23.23.192/32 -j VPN_176.23.23.192 -A PREROUTING -d 176.23.23.192/32 -j FIREWALL_176.23.23.192 -A PREROUTING -m state --state RELATED,ESTABLISHED -j CONNMARK --restore-mark --nfmask 0x --ctmask 0x -A POSTROUTING -p udp -m udp --dport 68 -j CHECKSUM --checksum-fill -A FIREWALL_176.23.23.192 -m state --state RELATED,ESTABLISHED -j ACCEPT -A FIREWALL_176.23.23.192 -j DROP -A VPN_176.23.23.192 -m state --state RELATED,ESTABLISHED -j ACCEPT -A VPN_176.23.23.192 -j RETURN COMMIT # Completed on Fri Apr 11 20:49:46 2014 # Generated by iptables-save v1.4.14 on Fri Apr 11 20:49:46 2014 *filter :INPUT DROP [68:32168] :FORWARD DROP [0:0] :OUTPUT ACCEPT [81:12516] :FW_EGRESS_RULES - [0:0] :FW_OUTBOUND - [0:0] :NETWORK_STATS - [0:0] -A INPUT -j NETWORK_STATS -A INPUT -d 224.0.0.18/32 -j ACCEPT -A INPUT -d 225.0.0.50/32 -j ACCEPT -A INPUT -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -i eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -i eth2 -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -p icmp -j ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -i eth0 -p udp -m udp --dport 67 -j ACCEPT -A INPUT -i eth0 -p udp -m udp --dport 53 -j ACCEPT -A INPUT -i eth0 -p tcp -m tcp --dport 53 -j ACCEPT -A INPUT -i eth1 -p tcp -m state --state NEW -m tcp --dport 3922 -j ACCEPT -A INPUT -i eth0 -p tcp
Upgrade from 4.1.1 to 4.3.0 ( KVM, Traffic labels, Adv. VLAN ) VR's bug
Hi After upgrade and restarting system-VM's all VR started with some bad network configuration, egress rules stopped work. also some staticNAT rules, there is ip addr show from one of VR's root@r-256-VM:~# ip addr show 1: lo: LOOPBACK,UP,LOWER_UP mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 02:00:6b:16:00:09 brd ff:ff:ff:ff:ff:ff inet 10.1.1.1/24 brd 10.1.1.255 scope global eth0 inet6 fe80::6bff:fe16:9/64 scope link valid_lft forever preferred_lft forever 3: eth1: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 0e:00:a9:fe:01:38 brd ff:ff:ff:ff:ff:ff inet 169.254.1.56/16 brd 169.254.255.255 scope global eth1 inet6 fe80::c00:a9ff:fefe:138/64 scope link valid_lft forever preferred_lft forever 4: eth2: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 06:06:ec:00:00:0e brd ff:ff:ff:ff:ff:ff inet XXX.XXX.XXX.219/26 brd 46.165.231.255 scope global eth2 inet6 fe80::406:ecff:fe00:e/64 scope link valid_lft forever preferred_lft forever 5: eth3: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 06:81:44:00:00:0e brd ff:ff:ff:ff:ff:ff inet XXX.XXX.XXX.219/26 brd 46.165.231.255 scope global eth3 inet XXX.XXX.XXX.230/26 brd 46.165.231.255 scope global secondary eth3 inet XXX.XXX.XXX.228/26 brd 46.165.231.255 scope global secondary eth3 inet XXX.XXX.XXX.209/26 brd 46.165.231.255 scope global secondary eth3 inet XXX.XXX.XXX.247/26 brd 46.165.231.255 scope global secondary eth3 inet XXX.XXX.XXX.227/26 brd 46.165.231.255 scope global secondary eth3 inet6 fe80::481:44ff:fe00:e/64 scope link valid_lft forever preferred_lft forever 6: eth4: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 06:e5:36:00:00:0e brd ff:ff:ff:ff:ff:ff inet XXX.XXX.XXX.219/26 brd 46.165.231.255 scope global eth4 inet XXX.XXX.XXX.247/26 brd 46.165.231.255 scope global secondary eth4 inet XXX.XXX.XXX.209/26 brd 46.165.231.255 scope global secondary eth4 inet XXX.XXX.XXX.227/26 brd 46.165.231.255 scope global secondary eth4 inet XXX.XXX.XXX.230/26 brd 46.165.231.255 scope global secondary eth4 inet6 fe80::4e5:36ff:fe00:e/64 scope link valid_lft forever preferred_lft forever 7: eth5: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 06:6f:3a:00:00:0e brd ff:ff:ff:ff:ff:ff inet XXX.XXX.XXX.219/26 brd 46.165.231.255 scope global eth5 inet XXX.XXX.XXX.228/26 brd 46.165.231.255 scope global secondary eth5 inet XXX.XXX.XXX.227/26 brd 46.165.231.255 scope global secondary eth5 inet XXX.XXX.XXX.209/26 brd 46.165.231.255 scope global secondary eth5 inet XXX.XXX.XXX.247/26 brd 46.165.231.255 scope global secondary eth5 inet XXX.XXX.XXX.230/26 brd 46.165.231.255 scope global secondary eth5 inet6 fe80::46f:3aff:fe00:e/64 scope link valid_lft forever preferred_lft forever 8: eth6: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 06:b0:30:00:00:0e brd ff:ff:ff:ff:ff:ff inet XXX.XXX.XXX.219/26 brd 46.165.231.255 scope global eth6 inet XXX.XXX.XXX.209/26 brd 46.165.231.255 scope global secondary eth6 inet XXX.XXX.XXX.247/26 brd 46.165.231.255 scope global secondary eth6 inet XXX.XXX.XXX.230/26 brd 46.165.231.255 scope global secondary eth6 inet XXX.XXX.XXX.227/26 brd 46.165.231.255 scope global secondary eth6 inet6 fe80::4b0:30ff:fe00:e/64 scope link valid_lft forever preferred_lft forever 9: eth7: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 06:26:b4:00:00:0e brd ff:ff:ff:ff:ff:ff inet XXX.XXX.XXX.219/26 brd 46.165.231.255 scope global eth7 inet XXX.XXX.XXX.247/26 brd 46.165.231.255 scope global secondary eth7 inet XXX.XXX.XXX.228/26 brd 46.165.231.255 scope global secondary eth7 inet XXX.XXX.XXX.230/26 brd 46.165.231.255 scope global secondary eth7 inet XXX.XXX.XXX.209/26 brd 46.165.231.255 scope global secondary eth7 inet XXX.XXX.XXX.227/26 brd 46.165.231.255 scope global secondary eth7 inet6 fe80::426:b4ff:fe00:e/64 scope link valid_lft forever preferred_lft forever -- ttyv0 /usr/libexec/gmail Pc webcons on secure
Re: Cloudstack 4.3 instances can't access outside world
Hi, I have same issue after upgrade 4.1.1 to 4.3.0 Take a look, in CS4.2 VR you have NIC's eth0,eth1,eth2. In CS 4.3 VR you have 4 NIC's where the eth2 and eth3 is the same. How CS4.3 is passed the QA? On Sat, Apr 12, 2014 at 12:16 AM, motty cruz motty.c...@gmail.com wrote: I have a testing cloudstack cluster, I destroyed it and rebuilding upgraded serveral times, each time I ran into the same problem, unable to access outside world from instances behind virtual router. here is iptables before upgrade, Cloudstack 4.2 # Generated by iptables-save v1.4.14 on Fri Apr 11 19:53:57 2014 *mangle :PREROUTING ACCEPT [2317:1282555] :INPUT ACCEPT [409:147015] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [189:29312] :POSTROUTING ACCEPT [189:29312] :FIREWALL_176.23.23.192 - [0:0] :VPN_176.23.23.192 - [0:0] -A PREROUTING -d 176.23.23.192/32 -j VPN_176.23.23.192 -A PREROUTING -d 176.23.23.192/32 -j FIREWALL_176.23.23.192 -A PREROUTING -m state --state RELATED,ESTABLISHED -j CONNMARK --restore-mark --nfmask 0x --ctmask 0x -A POSTROUTING -p udp -m udp --dport 68 -j CHECKSUM --checksum-fill -A FIREWALL_176.23.23.192 -m state --state RELATED,ESTABLISHED -j ACCEPT -A FIREWALL_176.23.23.192 -j DROP -A VPN_176.23.23.192 -m state --state RELATED,ESTABLISHED -j ACCEPT -A VPN_176.23.23.192 -j RETURN COMMIT # Completed on Fri Apr 11 19:53:57 2014 # Generated by iptables-save v1.4.14 on Fri Apr 11 19:53:57 2014 *filter :INPUT DROP [204:117504] :FORWARD DROP [0:0] :OUTPUT ACCEPT [150:22404] :FW_OUTBOUND - [0:0] :NETWORK_STATS - [0:0] -A INPUT -j NETWORK_STATS -A INPUT -d 224.0.0.18/32 -j ACCEPT -A INPUT -d 225.0.0.50/32 -j ACCEPT -A INPUT -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -i eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -i eth2 -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -p icmp -j ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -i eth0 -p udp -m udp --dport 67 -j ACCEPT -A INPUT -i eth0 -p udp -m udp --dport 53 -j ACCEPT -A INPUT -i eth0 -p tcp -m tcp --dport 53 -j ACCEPT -A INPUT -i eth1 -p tcp -m state --state NEW -m tcp --dport 3922 -j ACCEPT -A INPUT -i eth0 -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT -A INPUT -s 10.1.1.0/24 -i eth0 -p tcp -m state --state NEW -m tcp --dport 8080 -j ACCEPT -A FORWARD -j NETWORK_STATS -A FORWARD -i eth0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT -A FORWARD -i eth0 -o eth0 -m state --state NEW -j ACCEPT -A FORWARD -i eth0 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT -A FORWARD -i eth2 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT -A FORWARD -i eth0 -o eth2 -j FW_OUTBOUND -A OUTPUT -j NETWORK_STATS -A FW_OUTBOUND -m state --state RELATED,ESTABLISHED -j ACCEPT -A NETWORK_STATS -i eth0 -o eth2 -A NETWORK_STATS -i eth2 -o eth0 -A NETWORK_STATS ! -i eth0 -o eth2 -p tcp -A NETWORK_STATS -i eth2 ! -o eth0 -p tcp COMMIT # Completed on Fri Apr 11 19:53:57 2014 # Generated by iptables-save v1.4.14 on Fri Apr 11 19:53:57 2014 *nat :PREROUTING ACCEPT [2078:1204416] :INPUT ACCEPT [10:964] :OUTPUT ACCEPT [1:338] :POSTROUTING ACCEPT [1:338] -A POSTROUTING -o eth2 -j SNAT --to-source 176.23.23.192 COMMIT # Completed on Fri Apr 11 19:53:57 2014 after upgrading to Cloudstack 4.3 :POSTROUTING ACCEPT [211:25828] :FIREWALL_176.23.23.192 - [0:0] :VPN_176.23.23.192 - [0:0] -A PREROUTING -d 176.23.23.192/32 -j VPN_176.23.23.192 -A PREROUTING -d 176.23.23.192/32 -j FIREWALL_176.23.23.192 -A PREROUTING -m state --state RELATED,ESTABLISHED -j CONNMARK --restore-mark --nfmask 0x --ctmask 0x -A POSTROUTING -p udp -m udp --dport 68 -j CHECKSUM --checksum-fill -A FIREWALL_176.23.23.192 -m state --state RELATED,ESTABLISHED -j ACCEPT -A FIREWALL_176.23.23.192 -j DROP -A VPN_176.23.23.192 -m state --state RELATED,ESTABLISHED -j ACCEPT -A VPN_176.23.23.192 -j RETURN COMMIT # Completed on Fri Apr 11 20:49:46 2014 # Generated by iptables-save v1.4.14 on Fri Apr 11 20:49:46 2014 *filter :INPUT DROP [68:32168] :FORWARD DROP [0:0] :OUTPUT ACCEPT [81:12516] :FW_EGRESS_RULES - [0:0] :FW_OUTBOUND - [0:0] :NETWORK_STATS - [0:0] -A INPUT -j NETWORK_STATS -A INPUT -d 224.0.0.18/32 -j ACCEPT -A INPUT -d 225.0.0.50/32 -j ACCEPT -A INPUT -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -i eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -i eth2 -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -p icmp -j ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -i eth0 -p udp -m udp --dport 67 -j ACCEPT -A INPUT -i eth0 -p udp -m udp --dport 53 -j ACCEPT -A INPUT -i eth0 -p tcp -m tcp --dport 53 -j ACCEPT -A INPUT -i eth1 -p tcp -m state --state NEW -m tcp --dport 3922 -j ACCEPT -A INPUT -i eth0 -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT -j ACCEPT -A FORWARD -j NETWORK_STATS -A FORWARD -i eth0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT -A FORWARD -i eth2 -o eth0 -m state
Re: Cloudstack 4.3 instances can't access outside world
Hi, What does mean In 4.3 traffic labels are not considering ? It's temporary or traffic labels is deprecated now ? Does mean, anyone with KVM traffic labels environment can't upgrade to 4.3.0? On Thu, Apr 10, 2014 at 5:05 PM, Suresh Sadhu suresh.sa...@citrix.comwrote: Did you used traffic name labels? In 4.3 traffic labels are not considering ,by default its attaching to default traffic labels(eg:in KVM its cloudbr0 ...due to this unable to access public network i.r before upgrade if ieth2 attached cloudbr1 and after upgrade its attached to cloudbr0).maybe you are hitting this issue. Regards sadhu -Original Message- From: motty cruz [mailto:motty.c...@gmail.com] Sent: 10 April 2014 19:28 To: users@cloudstack.apache.org Subject: Re: Cloudstack 4.3 instances can't access outside world yes I can ping VR, also after the upgrade VR has four insterfaces, eth0 subnet for Instances, eth1, eth2 for public IP and eth3 for public IP. On Wed, Apr 9, 2014 at 10:35 PM, Erik Weber terbol...@gmail.com wrote: Can you ping the VR? Log on to the VR, and get the iptables rules. How do they look? Erik Weber 10. apr. 2014 00:21 skrev motty cruz motty.c...@gmail.com følgende: I did add egress rules, reboot network but no sucess, so I removed that rules and nothing. I am lost. On Wed, Apr 9, 2014 at 9:08 AM, Erik Weber terbol...@gmail.com wrote: Did you remove the egress rule again? If not, try that. Erik 9. apr. 2014 15:49 skrev motty cruz motty.c...@gmail.com følgende: yes I try adding the rule, restart network and router but no success! On Tue, Apr 8, 2014 at 11:16 PM, Erik Weber terbol...@gmail.com wrote: Try adding an egress rule, and removing it again. We experience the same, but has so far believed it was because we changed the default rule from deny to allow after accounts were made.. On Tue, Apr 8, 2014 at 11:14 PM, motty cruz motty.c...@gmail.com wrote: I have two isolated network both virtual routers can ping anywhere, but the Instances behind the virtual router can't ping or access the internet. On Tue, Apr 8, 2014 at 10:38 AM, motty cruz motty.c...@gmail.com wrote: Hello, I'm having issues with VMs unable to access outside world. I can ping gateway, also when I log in to virtual router, I am able to ping google.com or anywhere. in the Egress rules I am allowing all. reboot network and virtual router does not help. VMs were able to access outside before upgrading from 4.2 to 4.3. any ideas? -- ttyv0 /usr/libexec/gmail Pc webcons on secure
Re: Upgrade from 4.1.1 to 4.3.0 ( KVM, Traffic labels, Adv. VLAN ) VR's bug
Hi, Yes sure, root@r-256-VM:~# cat /etc/cloudstack-release Cloudstack Release 4.3.0 (64-bit) Wed Jan 15 00:27:19 UTC 2014 Also I tried to destroy the VR and re-create, VR up with same problem. The cloudstack-sysvmadm script haven't receive success answer from VR's. I have a finish rolling back to 4.1.1 - VR's successfully started, everything is work again, but how to upgrade to 4.3 ? This bug is not documented in know issue's, On Mon, Apr 21, 2014 at 8:16 AM, Marcus shadow...@gmail.com wrote: No idea, but have you verified that the vm is running the new system vm template? What happens if you destroy the router and let it recreate? On Sun, Apr 20, 2014 at 6:20 PM, Serg Senko kernc...@gmail.com wrote: Hi After upgrade and restarting system-VM's all VR started with some bad network configuration, egress rules stopped work. also some staticNAT rules, there is ip addr show from one of VR's root@r-256-VM:~# ip addr show 1: lo: LOOPBACK,UP,LOWER_UP mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 02:00:6b:16:00:09 brd ff:ff:ff:ff:ff:ff inet 10.1.1.1/24 brd 10.1.1.255 scope global eth0 inet6 fe80::6bff:fe16:9/64 scope link valid_lft forever preferred_lft forever 3: eth1: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 0e:00:a9:fe:01:38 brd ff:ff:ff:ff:ff:ff inet 169.254.1.56/16 brd 169.254.255.255 scope global eth1 inet6 fe80::c00:a9ff:fefe:138/64 scope link valid_lft forever preferred_lft forever 4: eth2: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 06:06:ec:00:00:0e brd ff:ff:ff:ff:ff:ff inet XXX.XXX.XXX.219/26 brd 46.165.231.255 scope global eth2 inet6 fe80::406:ecff:fe00:e/64 scope link valid_lft forever preferred_lft forever 5: eth3: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 06:81:44:00:00:0e brd ff:ff:ff:ff:ff:ff inet XXX.XXX.XXX.219/26 brd 46.165.231.255 scope global eth3 inet XXX.XXX.XXX.230/26 brd 46.165.231.255 scope global secondary eth3 inet XXX.XXX.XXX.228/26 brd 46.165.231.255 scope global secondary eth3 inet XXX.XXX.XXX.209/26 brd 46.165.231.255 scope global secondary eth3 inet XXX.XXX.XXX.247/26 brd 46.165.231.255 scope global secondary eth3 inet XXX.XXX.XXX.227/26 brd 46.165.231.255 scope global secondary eth3 inet6 fe80::481:44ff:fe00:e/64 scope link valid_lft forever preferred_lft forever 6: eth4: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 06:e5:36:00:00:0e brd ff:ff:ff:ff:ff:ff inet XXX.XXX.XXX.219/26 brd 46.165.231.255 scope global eth4 inet XXX.XXX.XXX.247/26 brd 46.165.231.255 scope global secondary eth4 inet XXX.XXX.XXX.209/26 brd 46.165.231.255 scope global secondary eth4 inet XXX.XXX.XXX.227/26 brd 46.165.231.255 scope global secondary eth4 inet XXX.XXX.XXX.230/26 brd 46.165.231.255 scope global secondary eth4 inet6 fe80::4e5:36ff:fe00:e/64 scope link valid_lft forever preferred_lft forever 7: eth5: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 06:6f:3a:00:00:0e brd ff:ff:ff:ff:ff:ff inet XXX.XXX.XXX.219/26 brd 46.165.231.255 scope global eth5 inet XXX.XXX.XXX.228/26 brd 46.165.231.255 scope global secondary eth5 inet XXX.XXX.XXX.227/26 brd 46.165.231.255 scope global secondary eth5 inet XXX.XXX.XXX.209/26 brd 46.165.231.255 scope global secondary eth5 inet XXX.XXX.XXX.247/26 brd 46.165.231.255 scope global secondary eth5 inet XXX.XXX.XXX.230/26 brd 46.165.231.255 scope global secondary eth5 inet6 fe80::46f:3aff:fe00:e/64 scope link valid_lft forever preferred_lft forever 8: eth6: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 06:b0:30:00:00:0e brd ff:ff:ff:ff:ff:ff inet XXX.XXX.XXX.219/26 brd 46.165.231.255 scope global eth6 inet XXX.XXX.XXX.209/26 brd 46.165.231.255 scope global secondary eth6 inet XXX.XXX.XXX.247/26 brd 46.165.231.255 scope global secondary eth6 inet XXX.XXX.XXX.230/26 brd 46.165.231.255 scope global secondary eth6 inet XXX.XXX.XXX.227/26 brd 46.165.231.255 scope global secondary eth6 inet6 fe80::4b0:30ff:fe00:e/64 scope link valid_lft forever preferred_lft forever 9: eth7: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP qlen
KVM, Re-create VR failed
Hi, It's can be some know bug? Possible it's already solved in new releases of CS but i need the work-around or fix before upgrade or reference to bug id. Environment: CS 4.1.1 libvirt-1.0.1 qemu-kvm-1.2 NFS Storage ( as primary for VR's ) Advanced VLAN isolation After hypervisor host crashing, one of VR's has failed to start in failover case, I have stopped it through UI with force, then was removed the VR for re-create it again by start/create VM API call. Try to start the Instance associated with this network, but failed because the VR can't be started when newly created. cloudstack-agent: 2014-04-11 07:05:34,546 DEBUG [kvm.resource.LibvirtComputingResource] (agentRequest-Handler-2:null) Failed to get dom xml: org.libvirt.LibvirtException: Domain not found: no domain with matching uuid '373ab4a9-cb8c-3275-a455-b9b4b963a983' 2014-04-11 07:05:34,547 DEBUG [kvm.resource.LibvirtComputingResource] (agentRequest-Handler-2:null) Failed to get dom xml: org.libvirt.LibvirtException: Domain not found: no domain with matching uuid '373ab4a9-cb8c-3275-a455-b9b4b963a983' 2014-04-11 07:05:34,548 DEBUG [kvm.resource.LibvirtComputingResource] (agentRequest-Handler-2:null) Failed to get dom xml: org.libvirt.LibvirtException: Domain not found: no domain with matching uuid '373ab4a9-cb8c-3275-a455-b9b4b963a983' 2014-04-11 07:05:34,548 DEBUG [kvm.resource.LibvirtComputingResource] (agentRequest-Handler-2:null) Executing: /usr/share/cloudstack-common/scripts/vm/network/security_group.py destroy_network_rules_for_vm --vmname r-377-VM 2014-04-11 07:05:34,663 DEBUG [kvm.resource.LibvirtComputingResource] (agentRequest-Handler-2:null) Execution is successful. 2014-04-11 07:05:34,664 DEBUG [kvm.resource.LibvirtComputingResource] (agentRequest-Handler-2:null) Try to stop the vm at first 2014-04-11 07:05:34,665 DEBUG [kvm.resource.LibvirtComputingResource] (agentRequest-Handler-2:null) Failed to stop VM :r-377-VM : org.libvirt.LibvirtException: Domain not found: no domain with matching uuid '373ab4a9-cb8c-3275-a455-b9b4b963a983' at org.libvirt.ErrorHandler.processError(Unknown Source) at org.libvirt.Connect.processError(Unknown Source) at org.libvirt.Connect.domainLookupByUUIDString(Unknown Source) at org.libvirt.Connect.domainLookupByUUID(Unknown Source) at com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.stopVM(LibvirtComputingResource.java:4021) at com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.stopVM(LibvirtComputingResource.java:3970) at com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.execute(LibvirtComputingResource.java:2894) at com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.executeRequest(LibvirtComputingResource.java:1032) at com.cloud.agent.Agent.processRequest(Agent.java:525) at com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:852) at com.cloud.utils.nio.Task.run(Task.java:83) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:679) 2014-04-11 07:05:34,666 DEBUG [kvm.resource.LibvirtComputingResource] (agentRequest-Handler-2:null) Failed to get vm status:Domain not found: no domain with matching uuid '373ab4a9-cb8c-3275-a455-b9b4b963a983' 2014-04-11 07:05:34,667 DEBUG [kvm.resource.LibvirtComputingResource] (agentRequest-Handler-2:null) Failed to get vm status:Domain not found: no domain with matching uuid '373ab4a9-cb8c-3275-a455-b9b4b963a983' 2014-04-11 07:05:34,668 DEBUG [kvm.resource.LibvirtComputingResource] (agentRequest-Handler-2:null) Failed to get vm status:Domain not found: no domain with matching uuid '373ab4a9-cb8c-3275-a455-b9b4b963a983' Management CS: 2014-04-11 07:05:40,503 DEBUG [network.router.VirtualNetworkApplianceManagerImpl] (Job-Executor-114:job-3001) Found 5 ip(s) to apply as a part of domR VM[DomainRouter|r-377-VM] start. 2014-04-11 07:05:40,528 DEBUG [network.router.VirtualNetworkApplianceManagerImpl] (Job-Executor-114:job-3001) Resending ipAssoc, port forwarding, load balancing rules as a part of Virtual router start 2014-04-11 07:05:40,542 DEBUG [network.router.VirtualNetworkApplianceManagerImpl] (Job-Executor-114:job-3001) Found 1 firewall Egress rule(s) to apply as a part of domR VM[DomainRouter|r-377-VM] start. 2014-04-11 07:05:40,581 ERROR [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-114:job-3001) Failed to start instance VM[DomainRouter|r-377-VM] java.lang.NullPointerException at com.cloud.network.NetworkModelImpl.getIpInNetwork(NetworkModelImpl.java:763) at com.cloud.network.router.VirtualNetworkApplianceManagerImpl.finalizeNetworkRulesForNetwork(VirtualNetworkApplianceManagerImpl.java:2346) at com.cloud.network.router.VpcVirtualNetworkApplianceManagerImpl.finalizeNetworkRulesForNetwork(VpcVirtualNetworkApplianceManagerImpl.java:928) at
Re: Unable to start VM
Hi, I have same error after computing node restaring ... Did you find solution? fix ? On Sat, Nov 16, 2013 at 3:17 PM, m2m isb isb...@gmail.com wrote: Hello All We have a problem about Starting VMs. We have a ClousdStack 4.1.1 running with KVM, Unable to start VMs with Following error. CloudStack management Server Log. /var/log/cloudstack/management/management-server.log 2013-11-16 14:30:56,859 DEBUG [cloud.deploy.FirstFitPlanner] (Job-Executor-14:job-926) DataCenter id = '2' provided is in avoid set, DeploymentPlanner cannot allocate the VM, returning. 2013-11-16 14:30:56,874 DEBUG [cloud.capacity.CapacityManagerImpl] (Job-Executor-14:job-926) VM state transitted from :Starting to Stopped with event: OperationFailedvm's original host id: null new host id: null host id before state transition: 28 2013-11-16 14:30:56,879 DEBUG [cloud.capacity.CapacityManagerImpl] (Job-Executor-14:job-926) Hosts's actual total CPU: 59832 and CPU after applying overprovisioning: 119664 2013-11-16 14:30:56,879 DEBUG [cloud.capacity.CapacityManagerImpl] (Job-Executor-14:job-926) release cpu from host: 28, old used: 21480,reserved: 4096, actual total: 59832, total with overprovisioning: 119664; new used: 17384,reserved:4096; movedfromreserved: false,moveToReserveredfalse 2013-11-16 14:30:56,879 DEBUG [cloud.capacity.CapacityManagerImpl] (Job-Executor-14:job-926) release mem from host: 28, old used: 22682796032,reserved: 4294967296, total: 67519684608; new used: 18387828736,reserved:4294967296; movedfromreserved: false,moveToReserveredfalse 2013-11-16 14:30:56,895 ERROR [cloud.async.AsyncJobManagerImpl] (Job-Executor-14:job-926) Unexpected exception while executing org.apache.cloudstack.api.command.user.vm.StartVMCmd com.cloud.exception.InsufficientServerCapacityException: Unable to create a deployment for VM[User|m2m-vdgw02]Scope=interface com.cloud.dc.DataCenter; id=2 at com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:728) at com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:471) at org.apache.cloudstack.engine.cloud.entity.api.VMEntityManagerImpl.deployVirtualMachine(VMEntityManagerImpl.java:212) at org.apache.cloudstack.engine.cloud.entity.api.VirtualMachineEntityImpl.deploy(VirtualMachineEntityImpl.java:209) at com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:3871) at com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:2579) at com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) at org.apache.cloudstack.api.command.user.vm.StartVMCmd.execute(StartVMCmd.java:120) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:162) at com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:437) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:679) 2013-11-16 14:30:56,895 DEBUG [cloud.async.AsyncJobManagerImpl] (Job-Executor-14:job-926) Complete async job-926, jobStatus: 2, resultCode: 530, result: Error Code: 530 Error text: Unable to create a deployment for VM[User|m2m-vdgw02] CloudStack Computing Node 013-11-16 15:36:57,148 DEBUG [kvm.resource.LibvirtComputingResource] (agentRequest-Handler-4:null) Execution is successful. 2013-11-16 15:36:57,149 DEBUG [kvm.resource.LibvirtComputingResource] (agentRequest-Handler-4:null) Try to stop the vm at first 2013-11-16 15:36:57,152 DEBUG [kvm.resource.LibvirtComputingResource] (agentRequest-Handler-4:null) Failed to stop VM :i-3-110-VM : org.libvirt.LibvirtException: ドメインは見つかりませんでした: UUID '40a685f6-405a-3fef-8591-b73f00a4cdd3' に一致するドメインがありません at org.libvirt.ErrorHandler.processError(Unknown Source) at org.libvirt.Connect.processError(Unknown Source) at org.libvirt.Connect.domainLookupByUUIDString(Unknown Source) at org.libvirt.Connect.domainLookupByUUID(Unknown Source) at com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.stopVM(LibvirtComputingResource.java:4021) at com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.stopVM(LibvirtComputingResource.java:3970) at com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.execute(LibvirtComputingResource.java:2894) at com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.executeRequest(LibvirtComputingResource.java:1032) at com.cloud.agent.Agent.processRequest(Agent.java:525) at com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:852) at com.cloud.utils.nio.Task.run(Task.java:83) at
