cloudstack-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jon Marshall <>
Subject Re: Possible bug fix - sanity check please
Date Fri, 25 Jan 2019 08:30:49 GMT
Hi Yiping

It is this related  bug -

Have a look at the comments but to summarise you need to replace this line (line 490) -

    if ips[0] == "0":

with -

if len(ips) == 0 or ips[0] == "0":

I have tested it and it fixes the problem I was seeing.

The fix will be included in 4.11.3 apparently.


From: Yiping Zhang <>
Sent: 24 January 2019 23:18
Subject: Re: Possible bug fix - sanity check please

Hi, Jon:

Would you please describe this bug a little more? How do I reproduce it?  Is there a Jira
or Github issue number for it?

It sounds like a bug in affecting VM live migration.  I am in the middle of upgrading
to, and on my lab system I see that the line 488 of file /usr/share/cloudstack-common/scripts/vm/network/
does have a ";" instead of a ":".



´╗┐On 1/24/19, 12:54 AM, "Jon Marshall" <> wrote:

    Please ignore, it has already been fixed but it is not included in the 4.11.2 release
(due in the 4.11.3 one).

    From: Jon Marshall <>
    Sent: 23 January 2019 15:30
    Subject: Possible bug fix - sanity check please

    The following issue was seen using  CS 4.11.2 in advanced mode with security group isolation.

    VM (internal name i-2-29-VM)  - is created and works fine with default security group
allowing inbound SSH and ICMP echo request.

    Migrate the VM to another of the compute nodes and the VM migrates and from the proxy
console the VM can connect out but the default security group inbound is not copied across
the compute node.   The /var/log/cloudstack/agent/security_group.log shows on the compute
node the VM has migrated to -

    2019-01-18 14:54:25,724 - Ignoring failure to delete ebtables chain for vm i-2-29-VM
    2019-01-18 14:54:25,724 - ebtables -t nat -F i-2-29-VM-out
    2019-01-18 14:54:25,730 - Ignoring failure to delete ebtables chain for vm i-2-29-VM
    2019-01-18 14:54:25,730 - ebtables -t nat -F i-2-29-VM-in-ips
    2019-01-18 14:54:25,735 - Ignoring failure to delete ebtables chain for vm i-2-29-VM
    2019-01-18 14:54:25,735 - ebtables -t nat -F i-2-29-VM-out-ips
    2019-01-18 14:54:25,740 - Ignoring failure to delete ebtables chain for vm i-2-29-VM
    2019-01-18 14:54:25,741 - iptables -N i-2-29-VM
    2019-01-18 14:54:25,745 - ip6tables -N i-2-29-VM
    2019-01-18 14:54:25,749 - iptables -N i-2-29-VM-eg
    2019-01-18 14:54:25,753 - ip6tables -N i-2-29-VM-eg
    2019-01-18 14:54:25,758 - iptables -N i-2-29-def
    2019-01-18 14:54:25,763 - ip6tables -N i-2-29-def
    2019-01-18 14:54:25,767 - Creating ipset chain .... i-2-29-VM
    2019-01-18 14:54:25,768 - ipset -F i-2-29-VM
    2019-01-18 14:54:25,772 - ipset chain not exists creating.... i-2-29-VM
    2019-01-18 14:54:25,772 - ipset -N i-2-29-VM iphash family inet
    2019-01-18 14:54:25,777 - vm ip 14:54:25,777 - ipset -A i-2-29-VM
    2019-01-18 14:54:25,782 - Failed to network rule !
    Traceback (most recent call last):
      File "/usr/share/cloudstack-common/scripts/vm/network/", 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/", line 490,
in default_network_rules
        if ips[0] == "0":
    IndexError: list index out of range

     Added a few lines to debug the script and it would appear this line
(line 487) is the culprit -

    ips = sec_ips.split(';')

    as far as I can tell the separator should be a colon (':') and not a semi colon or at
least on my setup.  Once changed to -

    ips = sec_ips.split(':')

    the iptables rules were updated correctly on the host the VM was migrated to.

    I don't know if this is the right change to make as the script is over a 1000 lines long
and imports other modules so woudl appreciate any input as this seems to be a key function
of Advanced with security groups.



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message