Re: Not able to access the vm from outside network
Version is 4.11.0.0 KVM Hypervisor Centos On Fri, Mar 1, 2019 at 10:57 AM soundar rajan wrote: > Hi Jon, > > Thanks that fix's the error but still i am not able to ping the vm > > > 2019-03-01 10:46:23,246 - ipset -A i-2-40-VM-6 fe80::1c00:26ff:fe00:9d > 2019-03-01 10:46:23,261 - ip6tables -A BF-cloudbr0-OUT -m physdev > --physdev-is-bridged --physdev-out vnet2 -j i-2-40-def > 2019-03-01 10:46:23,277 - ip6tables -A BF-cloudbr0-IN -m physdev > --physdev-is-bridged --physdev-in vnet2 -j i-2-40-def > 2019-03-01 10:46:23,293 - ip6tables -A i-2-40-def -m state --state > RELATED,ESTABLISHED -j ACCEPT > 2019-03-01 10:46:23,309 - ip6tables -A i-2-40-def -m physdev > --physdev-is-bridged --physdev-out vnet2 --src fe80::/64 --dst ff02::1 -p > icmpv6 --icmpv6-type router-advertisement -m hl --hl-eq 255 -j ACCEPT > 2019-03-01 10:46:23,327 - ip6tables -A i-2-40-def -m physdev > --physdev-is-bridged --physdev-in vnet2 --dst ff02::2 -p icmpv6 > --icmpv6-type router-solicitation -m hl --hl-eq 255 -j RETURN > 2019-03-01 10:46:23,344 - ip6tables -A i-2-40-def -m physdev > --physdev-is-bridged --physdev-in vnet2 -p icmpv6 --icmpv6-type > router-advertisement -j DROP > 2019-03-01 10:46:23,361 - ip6tables -A i-2-40-def -m physdev > --physdev-is-bridged --physdev-in vnet2 -p icmpv6 --icmpv6-type > neighbor-solicitation -m hl --hl-eq 255 -j RETURN > 2019-03-01 10:46:23,378 - ip6tables -A i-2-40-def -m physdev > --physdev-is-bridged --physdev-out vnet2 -p icmpv6 --icmpv6-type > neighbor-solicitation -m hl --hl-eq 255 -j ACCEPT > 2019-03-01 10:46:23,395 - ip6tables -A i-2-40-def -m physdev > --physdev-is-bridged --physdev-in vnet2 -p icmpv6 --icmpv6-type > neighbor-advertisement -m set --match-set i-2-40-VM-6 src -m hl --hl-eq 255 > -j RETURN > 2019-03-01 10:46:23,412 - ip6tables -A i-2-40-def -m physdev > --physdev-is-bridged --physdev-out vnet2 -p icmpv6 --icmpv6-type > neighbor-advertisement -m hl --hl-eq 255 -j ACCEPT > 2019-03-01 10:46:23,430 - ip6tables -A i-2-40-def -m physdev > --physdev-is-bridged --physdev-in vnet2 -p icmpv6 --icmpv6-type > packet-too-big -m set --match-set i-2-40-VM-6 src -j RETURN > 2019-03-01 10:46:23,447 - ip6tables -A i-2-40-def -m physdev > --physdev-is-bridged --physdev-out vnet2 -p icmpv6 --icmpv6-type > packet-too-big -j ACCEPT > 2019-03-01 10:46:23,464 - ip6tables -A i-2-40-def -m physdev > --physdev-is-bridged --physdev-in vnet2 -p icmpv6 --icmpv6-type > destination-unreachable -m set --match-set i-2-40-VM-6 src -j RETURN > 2019-03-01 10:46:23,482 - ip6tables -A i-2-40-def -m physdev > --physdev-is-bridged --physdev-out vnet2 -p icmpv6 --icmpv6-type > destination-unreachable -j ACCEPT > 2019-03-01 10:46:23,499 - ip6tables -A i-2-40-def -m physdev > --physdev-is-bridged --physdev-in vnet2 -p icmpv6 --icmpv6-type > time-exceeded -m set --match-set i-2-40-VM-6 src -j RETURN > 2019-03-01 10:46:23,516 - ip6tables -A i-2-40-def -m physdev > --physdev-is-bridged --physdev-out vnet2 -p icmpv6 --icmpv6-type > time-exceeded -j ACCEPT > 2019-03-01 10:46:23,533 - ip6tables -A i-2-40-def -m physdev > --physdev-is-bridged --physdev-in vnet2 -p icmpv6 --icmpv6-type > parameter-problem -m set --match-set i-2-40-VM-6 src -j RETURN > 2019-03-01 10:46:23,551 - ip6tables -A i-2-40-def -m physdev > --physdev-is-bridged --physdev-out vnet2 -p icmpv6 --icmpv6-type > parameter-problem -j ACCEPT > 2019-03-01 10:46:23,568 - ip6tables -A i-2-40-def -m physdev > --physdev-is-bridged --physdev-in vnet2 -p icmpv6 --dst ff02::16 -j RETURN > 2019-03-01 10:46:23,585 - ip6tables -A i-2-40-def -m physdev > --physdev-is-bridged --physdev-in vnet2 -p udp --sport 546 --dst ff02::1:2 > --src fe80::1c00:26ff:fe00:9d -j RETURN > 2019-03-01 10:46:23,602 - ip6tables -A i-2-40-def -m physdev > --physdev-is-bridged --physdev-out vnet2 -p udp --src fe80::/64 --dport 546 > --dst fe80::1c00:26ff:fe00:9d -j ACCEPT > 2019-03-01 10:46:23,620 - ip6tables -A i-2-40-def -m physdev > --physdev-is-bridged --physdev-in vnet2 -p udp --sport 547 ! --dst > fe80::/64 -j DROP > 2019-03-01 10:46:23,637 - ip6tables -A i-2-40-def -m physdev > --physdev-is-bridged --physdev-in vnet2 -p udp --dport 53 -m set > --match-set i-2-40-VM-6 src -j RETURN > 2019-03-01 10:46:23,655 - ip6tables -A i-2-40-def -m physdev > --physdev-is-bridged --physdev-in vnet2 -p tcp --dport 53 -m set > --match-set i-2-40-VM-6 src -j RETURN > 2019-03-01 10:46:23,672 - ip6tables -A i-2-40-def -m physdev > --physdev-is-bridged --physdev-in vnet2 -m set ! --match-set i-2-40-VM-6 > src -j DROP > 2019-03-01 10:46:23,689 - ip6tables -A i-2-40-def -m physdev > --physdev-is-bridged --physdev-in vnet2 -m set --match-set i-2-40-VM-6 src > -j i-2-40-VM-eg > 2019-03-01 10:46:23,706 - ip6tables -A i-2-40-def -m physdev > --physdev-is-bridged --physdev-out vnet2 -j i-2-40-VM > 2019-03-01 10:46:23,723 - ip6tables -A i-2-40-VM -j DROP > 2019-03-01 10:46:23,739 - Programmed default rules for vm i-2-40-VM > 2019-03-01 10:46:24,255 - Executing command: add_network_rules > 2019-03-01 10:46:24,259 -
Re: Not able to access the vm from outside network
Hi Jon, Thanks that fix's the error but still i am not able to ping the vm 2019-03-01 10:46:23,246 - ipset -A i-2-40-VM-6 fe80::1c00:26ff:fe00:9d 2019-03-01 10:46:23,261 - ip6tables -A BF-cloudbr0-OUT -m physdev --physdev-is-bridged --physdev-out vnet2 -j i-2-40-def 2019-03-01 10:46:23,277 - ip6tables -A BF-cloudbr0-IN -m physdev --physdev-is-bridged --physdev-in vnet2 -j i-2-40-def 2019-03-01 10:46:23,293 - ip6tables -A i-2-40-def -m state --state RELATED,ESTABLISHED -j ACCEPT 2019-03-01 10:46:23,309 - ip6tables -A i-2-40-def -m physdev --physdev-is-bridged --physdev-out vnet2 --src fe80::/64 --dst ff02::1 -p icmpv6 --icmpv6-type router-advertisement -m hl --hl-eq 255 -j ACCEPT 2019-03-01 10:46:23,327 - ip6tables -A i-2-40-def -m physdev --physdev-is-bridged --physdev-in vnet2 --dst ff02::2 -p icmpv6 --icmpv6-type router-solicitation -m hl --hl-eq 255 -j RETURN 2019-03-01 10:46:23,344 - ip6tables -A i-2-40-def -m physdev --physdev-is-bridged --physdev-in vnet2 -p icmpv6 --icmpv6-type router-advertisement -j DROP 2019-03-01 10:46:23,361 - ip6tables -A i-2-40-def -m physdev --physdev-is-bridged --physdev-in vnet2 -p icmpv6 --icmpv6-type neighbor-solicitation -m hl --hl-eq 255 -j RETURN 2019-03-01 10:46:23,378 - ip6tables -A i-2-40-def -m physdev --physdev-is-bridged --physdev-out vnet2 -p icmpv6 --icmpv6-type neighbor-solicitation -m hl --hl-eq 255 -j ACCEPT 2019-03-01 10:46:23,395 - ip6tables -A i-2-40-def -m physdev --physdev-is-bridged --physdev-in vnet2 -p icmpv6 --icmpv6-type neighbor-advertisement -m set --match-set i-2-40-VM-6 src -m hl --hl-eq 255 -j RETURN 2019-03-01 10:46:23,412 - ip6tables -A i-2-40-def -m physdev --physdev-is-bridged --physdev-out vnet2 -p icmpv6 --icmpv6-type neighbor-advertisement -m hl --hl-eq 255 -j ACCEPT 2019-03-01 10:46:23,430 - ip6tables -A i-2-40-def -m physdev --physdev-is-bridged --physdev-in vnet2 -p icmpv6 --icmpv6-type packet-too-big -m set --match-set i-2-40-VM-6 src -j RETURN 2019-03-01 10:46:23,447 - ip6tables -A i-2-40-def -m physdev --physdev-is-bridged --physdev-out vnet2 -p icmpv6 --icmpv6-type packet-too-big -j ACCEPT 2019-03-01 10:46:23,464 - ip6tables -A i-2-40-def -m physdev --physdev-is-bridged --physdev-in vnet2 -p icmpv6 --icmpv6-type destination-unreachable -m set --match-set i-2-40-VM-6 src -j RETURN 2019-03-01 10:46:23,482 - ip6tables -A i-2-40-def -m physdev --physdev-is-bridged --physdev-out vnet2 -p icmpv6 --icmpv6-type destination-unreachable -j ACCEPT 2019-03-01 10:46:23,499 - ip6tables -A i-2-40-def -m physdev --physdev-is-bridged --physdev-in vnet2 -p icmpv6 --icmpv6-type time-exceeded -m set --match-set i-2-40-VM-6 src -j RETURN 2019-03-01 10:46:23,516 - ip6tables -A i-2-40-def -m physdev --physdev-is-bridged --physdev-out vnet2 -p icmpv6 --icmpv6-type time-exceeded -j ACCEPT 2019-03-01 10:46:23,533 - ip6tables -A i-2-40-def -m physdev --physdev-is-bridged --physdev-in vnet2 -p icmpv6 --icmpv6-type parameter-problem -m set --match-set i-2-40-VM-6 src -j RETURN 2019-03-01 10:46:23,551 - ip6tables -A i-2-40-def -m physdev --physdev-is-bridged --physdev-out vnet2 -p icmpv6 --icmpv6-type parameter-problem -j ACCEPT 2019-03-01 10:46:23,568 - ip6tables -A i-2-40-def -m physdev --physdev-is-bridged --physdev-in vnet2 -p icmpv6 --dst ff02::16 -j RETURN 2019-03-01 10:46:23,585 - ip6tables -A i-2-40-def -m physdev --physdev-is-bridged --physdev-in vnet2 -p udp --sport 546 --dst ff02::1:2 --src fe80::1c00:26ff:fe00:9d -j RETURN 2019-03-01 10:46:23,602 - ip6tables -A i-2-40-def -m physdev --physdev-is-bridged --physdev-out vnet2 -p udp --src fe80::/64 --dport 546 --dst fe80::1c00:26ff:fe00:9d -j ACCEPT 2019-03-01 10:46:23,620 - ip6tables -A i-2-40-def -m physdev --physdev-is-bridged --physdev-in vnet2 -p udp --sport 547 ! --dst fe80::/64 -j DROP 2019-03-01 10:46:23,637 - ip6tables -A i-2-40-def -m physdev --physdev-is-bridged --physdev-in vnet2 -p udp --dport 53 -m set --match-set i-2-40-VM-6 src -j RETURN 2019-03-01 10:46:23,655 - ip6tables -A i-2-40-def -m physdev --physdev-is-bridged --physdev-in vnet2 -p tcp --dport 53 -m set --match-set i-2-40-VM-6 src -j RETURN 2019-03-01 10:46:23,672 - ip6tables -A i-2-40-def -m physdev --physdev-is-bridged --physdev-in vnet2 -m set ! --match-set i-2-40-VM-6 src -j DROP 2019-03-01 10:46:23,689 - ip6tables -A i-2-40-def -m physdev --physdev-is-bridged --physdev-in vnet2 -m set --match-set i-2-40-VM-6 src -j i-2-40-VM-eg 2019-03-01 10:46:23,706 - ip6tables -A i-2-40-def -m physdev --physdev-is-bridged --physdev-out vnet2 -j i-2-40-VM 2019-03-01 10:46:23,723 - ip6tables -A i-2-40-VM -j DROP 2019-03-01 10:46:23,739 - Programmed default rules for vm i-2-40-VM 2019-03-01 10:46:24,255 - Executing command: add_network_rules 2019-03-01 10:46:24,259 - programming network rules for IP: 172.20.109.167 vmname=i-2-40-VM 2019-03-01 10:46:24,260 - iptables -F i-2-40-VM 2019-03-01 10:46:24,273 - ip6tables -F i-2-40-VM 2019-03-01 10:46:24,287 - iptables -F i-2-40-VM-eg 2019-03-01 10:46:24,298 - ip6tables -F i-2-40-VM-eg
RE: Snapshots on KVM corrupting disk images
Hi Ivan, I wanted to respond here and see if you published a PR yet on this. This is a very scary issue for us as customer can snapshot their volumes and end up causing corruption - and they blame us. It's already happened - luckily we had Storage Array level snapshots in place as a safety net... Thanks!! Sean -Original Message- From: Ivan Kudryavtsev [mailto:kudryavtsev...@bw-sw.com] Sent: Sunday, January 27, 2019 7:29 PM To: users ; cloudstack-fan Cc: dev Subject: Re: Snapshots on KVM corrupting disk images Well, guys. I dived into CS agent scripts, which make volume snapshots and found there are no code for suspend/resume and also no code for qemu-agent call fsfreeze/fsthaw. I don't see any blockers adding that code yet and try to add it in nearest days. If tests go well, I'll publish the PR, which I suppose could be integrated into 4.11.3. пн, 28 янв. 2019 г., 2:45 cloudstack-fan cloudstack-...@protonmail.com.invalid: > Hello Sean, > > It seems that you've encountered the same issue that I've been facing > during the last 5-6 years of using ACS with KVM hosts (see this > thread, if you're interested in additional details: > https://mail-archives.apache.org/mod_mbox/cloudstack-users/201807.mbox > /browser > ). > > I'd like to state that creating snapshots of a running virtual machine > is a bit risky. I've implemented some workarounds in my environment, > but I'm still not sure that they are 100% effective. > > I have a couple of questions, if you don't mind. What kind of storage > do you use, if it's not a secret? Does you storage use XFS as a filesystem? > Did you see something like this in your log-files? > [***.***] XFS: qemu-kvm(***) possible memory allocation deadlock size > 65552 in kmem_realloc (mode:0x250) > [***.***] XFS: qemu-kvm(***) possible memory allocation deadlock size > 65552 in kmem_realloc (mode:0x250) > [***.***] XFS: qemu-kvm(***) possible memory allocation deadlock size > 65552 in kmem_realloc (mode:0x250) > Did you see any unusual messages in your log-file when the disaster > happened? > > I hope, things will be well. Wish you good luck and all the best! > > > ‐‐‐ Original Message ‐‐‐ > On Tuesday, 22 January 2019 18:30, Sean Lair wrote: > > > Hi all, > > > > We had some instances where VM disks are becoming corrupted when > > using > KVM snapshots. We are running CloudStack 4.9.3 with KVM on CentOS 7. > > > > The first time was when someone mass-enabled scheduled snapshots on > > a > lot of large number VMs and secondary storage filled up. We had to > restore all those VM disks... But believed it was just our fault with > letting secondary storage fill up. > > > > Today we had an instance where a snapshot failed and now the disk > > image > is corrupted and the VM can't boot. here is the output of some commands: > > > > > -- > -- > -- > -- > -- > -- > -- > > > > > [root@cloudkvm02 c3be0ae5-2248-3ed6-a0c7-acffe25cc8d3]# qemu-img > > check > ./184aa458-9d4b-4c1b-a3c6-23d28ea28e80 > > qemu-img: Could not open './184aa458-9d4b-4c1b-a3c6-23d28ea28e80': > > Could > not read snapshots: File too large > > > > [root@cloudkvm02 c3be0ae5-2248-3ed6-a0c7-acffe25cc8d3]# qemu-img > > info > ./184aa458-9d4b-4c1b-a3c6-23d28ea28e80 > > qemu-img: Could not open './184aa458-9d4b-4c1b-a3c6-23d28ea28e80': > > Could > not read snapshots: File too large > > > > [root@cloudkvm02 c3be0ae5-2248-3ed6-a0c7-acffe25cc8d3]# ls -lh > ./184aa458-9d4b-4c1b-a3c6-23d28ea28e80 > > -rw-r--r--. 1 root root 73G Jan 22 11:04 > ./184aa458-9d4b-4c1b-a3c6-23d28ea28e80 > > > > > -- > -- > -- > -- > -- > -- > -- > -- > --- > > > > We tried restoring to before the snapshot failure, but still have > strange errors: > > > > > -- > -- > > > > [root@cloudkvm02 c3be0ae5-2248-3ed6-a0c7-acffe25cc8d3]#
Re: Not able to access the vm from outside network
Is this after you migrated the VM to another compute node ?
It looks suspiciously like the issue I saw ie. I was using advanced networking
with security groups and the security policy for the VM was not migrated to the
new compute node.
There is a bug filed for it and a workaround -
https://github.com/apache/cloudstack/issues/3088
the fix is in the comments but basically you need to need to edit this file -
"/usr/share/cloudstack-common/scripts/vm/network/security_group.py"
and change line 490 from -
if ips[0] == "0":
to -
if len(ips) == 0 or ips[0] == "0":
and that should fix it.
The will be included in CS v4.11.3
Jon
From: soundar rajan
Sent: 28 February 2019 13:52
To: d...@cloudstack.apache.org; users@cloudstack.apache.org
Subject: Not able to access the vm from outside network
Hi,
VM outbound is working fine. Inbound is not not able to access from
outside network
Error Log
2019-02-28 18:12:25,112 - Failed to network rule !
Traceback (most recent call last):
File "/usr/share/cloudstack-common/scripts/vm/network/security_group.py",
line 995, in add_network_rules
default_network_rules(vmName, vm_id, vm_ip, vm_ip6, vmMac, vif, brname,
sec_ips)
File "/usr/share/cloudstack-common/scripts/vm/network/security_group.py",
line 490, in default_network_rules
if ips[0] == "0":
IndexError: list index out of range
2019-02-28 18:13:16,635 - Executing command: cleanup_rules
2019-02-28 18:13:16,645 - Vms on the host : ['i-2-40-VM', 'i-2-90-VM',
'i-2-112-VM']
2019-02-28 18:13:16,645 - iptables-save | grep -P '^:(?!.*-(def|eg))' | awk
'{sub(/^:/, "", $1) ; print $1}' | sort | uniq
2019-02-28 18:13:16,671 - iptables chains in the host :['BF-cloudbr0',
'BF-cloudbr0-IN', 'BF-cloudbr0-OUT', 'FORWARD', 'i-2-112-VM', 'i-2-40-VM',
'i-2-90-VM', 'INPUT', 'OUTPUT', 'POSTROUTING', 'PREROUTING', '']
2019-02-28 18:13:16,672 - grep -E '^ebtable_' /proc/modules | cut -f1 -d' '
| sed s/ebtable_//
2019-02-28 18:13:16,693 - ebtables -t nat -L | awk '/chain:/ {
gsub(/(^.*chain: |-(in|out|ips).*)/, ""); print $1}' | sort | uniq
2019-02-28 18:13:16,716 - ebtables -t filter -L | awk '/chain:/ {
gsub(/(^.*chain: |-(in|out|ips).*)/, ""); print $1}' | sort | uniq
2019-02-28 18:13:16,738 - ebtables chains in the host: ['FORWARD,',
'INPUT,', 'OUTPUT,', '']
2019-02-28 18:13:16,739 - Cleaned up rules for 0 chains
2019-02-28 18:13:23,959 - Executing command: get_rule_logs_for_vms
It happens to particular vm
Please help..
Re: System VMs cannot reach internet
On 2/28/19 7:19 AM, Fariborz Navidan wrote: Hello, It seems cloudstack does not configure system vms correctly. Even if I delete them and cloudstack recreates, they cannot reach internet however they can be reached from outside. When I check, I see no gateway is set on them. If I set manually, it willbe removed on next reboot. Please help! Version of Cloudstack? Compute host OS / hypervisor type? Cloudstack system VM image ID?
Re: installation troubles
> If you can, would you mind submitting a pull request to the > documentation repo > https://github.com/apache/cloudstack-documentation > to add the missing steps? Done: https://github.com/apache/cloudstack-documentation/pull/30
Re: Not able to access the vm from outside network
Hi,
ACS version, hypervisor (version) ?
On Thu, 28 Feb 2019 at 14:58, soundar rajan wrote:
> Hi,
>
> VM outbound is working fine. Inbound is not not able to access from
> outside network
>
> Error Log
> 2019-02-28 18:12:25,112 - Failed to network rule !
> Traceback (most recent call last):
> File "/usr/share/cloudstack-common/scripts/vm/network/security_group.py",
> line 995, in add_network_rules
> default_network_rules(vmName, vm_id, vm_ip, vm_ip6, vmMac, vif, brname,
> sec_ips)
> File "/usr/share/cloudstack-common/scripts/vm/network/security_group.py",
> line 490, in default_network_rules
> if ips[0] == "0":
> IndexError: list index out of range
> 2019-02-28 18:13:16,635 - Executing command: cleanup_rules
> 2019-02-28 18:13:16,645 - Vms on the host : ['i-2-40-VM', 'i-2-90-VM',
> 'i-2-112-VM']
> 2019-02-28 18:13:16,645 - iptables-save | grep -P '^:(?!.*-(def|eg))' | awk
> '{sub(/^:/, "", $1) ; print $1}' | sort | uniq
> 2019-02-28 18:13:16,671 - iptables chains in the host :['BF-cloudbr0',
> 'BF-cloudbr0-IN', 'BF-cloudbr0-OUT', 'FORWARD', 'i-2-112-VM', 'i-2-40-VM',
> 'i-2-90-VM', 'INPUT', 'OUTPUT', 'POSTROUTING', 'PREROUTING', '']
> 2019-02-28 18:13:16,672 - grep -E '^ebtable_' /proc/modules | cut -f1 -d' '
> | sed s/ebtable_//
> 2019-02-28 18:13:16,693 - ebtables -t nat -L | awk '/chain:/ {
> gsub(/(^.*chain: |-(in|out|ips).*)/, ""); print $1}' | sort | uniq
> 2019-02-28 18:13:16,716 - ebtables -t filter -L | awk '/chain:/ {
> gsub(/(^.*chain: |-(in|out|ips).*)/, ""); print $1}' | sort | uniq
> 2019-02-28 18:13:16,738 - ebtables chains in the host: ['FORWARD,',
> 'INPUT,', 'OUTPUT,', '']
> 2019-02-28 18:13:16,739 - Cleaned up rules for 0 chains
> 2019-02-28 18:13:23,959 - Executing command: get_rule_logs_for_vms
>
> It happens to particular vm
>
> Please help..
>
--
Andrija Panić
System VMs cannot reach internet
Hello, It seems cloudstack does not configure system vms correctly. Even if I delete them and cloudstack recreates, they cannot reach internet however they can be reached from outside. When I check, I see no gateway is set on them. If I set manually, it willbe removed on next reboot. Please help!
Not able to access the vm from outside network
Hi,
VM outbound is working fine. Inbound is not not able to access from
outside network
Error Log
2019-02-28 18:12:25,112 - Failed to network rule !
Traceback (most recent call last):
File "/usr/share/cloudstack-common/scripts/vm/network/security_group.py",
line 995, in add_network_rules
default_network_rules(vmName, vm_id, vm_ip, vm_ip6, vmMac, vif, brname,
sec_ips)
File "/usr/share/cloudstack-common/scripts/vm/network/security_group.py",
line 490, in default_network_rules
if ips[0] == "0":
IndexError: list index out of range
2019-02-28 18:13:16,635 - Executing command: cleanup_rules
2019-02-28 18:13:16,645 - Vms on the host : ['i-2-40-VM', 'i-2-90-VM',
'i-2-112-VM']
2019-02-28 18:13:16,645 - iptables-save | grep -P '^:(?!.*-(def|eg))' | awk
'{sub(/^:/, "", $1) ; print $1}' | sort | uniq
2019-02-28 18:13:16,671 - iptables chains in the host :['BF-cloudbr0',
'BF-cloudbr0-IN', 'BF-cloudbr0-OUT', 'FORWARD', 'i-2-112-VM', 'i-2-40-VM',
'i-2-90-VM', 'INPUT', 'OUTPUT', 'POSTROUTING', 'PREROUTING', '']
2019-02-28 18:13:16,672 - grep -E '^ebtable_' /proc/modules | cut -f1 -d' '
| sed s/ebtable_//
2019-02-28 18:13:16,693 - ebtables -t nat -L | awk '/chain:/ {
gsub(/(^.*chain: |-(in|out|ips).*)/, ""); print $1}' | sort | uniq
2019-02-28 18:13:16,716 - ebtables -t filter -L | awk '/chain:/ {
gsub(/(^.*chain: |-(in|out|ips).*)/, ""); print $1}' | sort | uniq
2019-02-28 18:13:16,738 - ebtables chains in the host: ['FORWARD,',
'INPUT,', 'OUTPUT,', '']
2019-02-28 18:13:16,739 - Cleaned up rules for 0 chains
2019-02-28 18:13:23,959 - Executing command: get_rule_logs_for_vms
It happens to particular vm
Please help..
