[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15924788#comment-15924788
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9811:
--------------------------------------------

Github user swill commented on the issue:

    https://github.com/apache/cloudstack/pull/2003
  
    This `ips.json` file confuses the hell out of me.  From what I can tell 
both `eth2` and `eth3` both have the ip `10.1.35.83` twice for each (for a 
total of the IP being configured 4 times over two interfaces).
    
    How was this IP configured?  
    
    ```
        "eth2": [
            {
                "add": true,
                "broadcast": "10.1.63.255",
                "cidr": "10.1.35.83/19",
                "device": "eth2",
                "gateway": "10.1.63.254",
                "netmask": "255.255.224.0",
                "network": "10.1.32.0/19",
                "nic_dev_id": "2",
                "nw_type": "public",
                "one_to_one_nat": false,
                "public_ip": "10.1.35.83",
                "size": "19",
                "source_nat": false
            },
            {
                "add": true,
                "broadcast": "10.1.63.255",
                "cidr": "10.1.35.83/19",
                "device": "eth2",
                "gateway": "10.1.63.254",
                "netmask": "255.255.224.0",
                "network": "10.1.32.0/19",
                "nic_dev_id": "2",
                "nw_type": "public",
                "one_to_one_nat": false,
                "public_ip": "10.1.35.83",
                "size": "19",
                "source_nat": false
            }
        ],
        "eth3": [
            {
                "add": true,
                "broadcast": "10.1.63.255",
                "cidr": "10.1.35.83/19",
                "device": "eth3",
                "first_i_p": true,
                "gateway": "10.1.63.254",
                "netmask": "255.255.224.0",
                "network": "10.1.32.0/19",
                "new_nic": true,
                "nic_dev_id": 3,
                "nw_type": "public",
                "one_to_one_nat": false,
                "public_ip": "10.1.35.83",
                "size": "19",
                "source_nat": true,
                "vif_mac_address": "06:ee:46:00:00:03"
            },
            {
                "add": true,
                "broadcast": "10.1.63.255",
                "cidr": "10.1.35.83/19",
                "device": "eth3",
                "first_i_p": true,
                "gateway": "10.1.63.254",
                "netmask": "255.255.224.0",
                "network": "10.1.32.0/19",
                "new_nic": true,
                "nic_dev_id": 3,
                "nw_type": "public",
                "one_to_one_nat": false,
                "public_ip": "10.1.35.83",
                "size": "19",
                "source_nat": true,
                "vif_mac_address": "06:a4:80:00:00:03"
            }
        ],
    ```
    
    I will see if I can get to the bottom of this, but this is pretty 
confusing.  Do you have a sequence of events which produced this configuration? 
 


> VR will not start, looking to configure eth3 while no such device exists on 
> the VR. On KVM-CentOS6.8 physical host
> ------------------------------------------------------------------------------------------------------------------
>
>                 Key: CLOUDSTACK-9811
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9811
>             Project: CloudStack
>          Issue Type: Bug
>      Security Level: Public(Anyone can view this level - this is the 
> default.) 
>          Components: Virtual Router
>    Affects Versions: 4.10.0.0
>            Reporter: Boris Stoyanov
>            Priority: Blocker
>         Attachments: agent.log, cloud.log, management.log
>
>
> This issue appears only on 4.10. When you add an instance with a new network 
> the VR starts and fails at the configuration point. Looks like it is looking 
> to configure eth3 adapter while no such device should be available on the VR. 
> The VR does not start and aborts the deployment of the VM. 
> Pease note that this issue was reproduced on physical KVM hosts in our lab.
> Hardware Hosts details:
> - 4x Dell C6100
> - Using: American Megatrends MegaRAC Baseboard Management (IPMI v2 compliant)
> OS:
> CentOS 6.8. 
> Management: 
> VM, running CentOS 6.8
> ACS version: 4.10 RC 1. SHA: 7c1d003b5269b375d87f4f6cfff8a144f0608b67
> In a nested virtualization environment it was working fine with CentOS6.8. 
> Attached are the management log and the cloud.log form the VR. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Reply via email to