cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <>
Subject [jira] [Commented] (CLOUDSTACK-9811) VR will not start, looking to configure eth3 while no such device exists on the VR. On KVM-CentOS6.8 physical host
Date Tue, 14 Mar 2017 14:05:41 GMT


ASF GitHub Bot commented on CLOUDSTACK-9811:

Github user swill commented on the issue:
    I have to admit, I am not sure how the IP was found when looping through the list initially,
but then when trying to update the index for the IP that was found, it is not there.  The
only way I can think of that would cause this is if the IP <-> dev mapping is broken
somehow.  It found the matching IP, but apparently that IP is not on the dev defined by the
`nic_dev_id` (which comes from either: `nic_dev_id = address['nic_dev_id']` (from the databag),
which can then be overridden by `nic_dev_id = ip['nic_dev_id']` (from the passed in IP) ).
    Yes, I think you are right that the `else` case does not work right now.  This is because
we are appending the IP to this dev, but we never removed it from the other dev it was apparently
found in.  This logic is SUPPOSED to find the existing IP's index and then if found, update
that index with the updated info.  
    The old logic which just removed all "found" IPs and then re-added them, did not preserve
the order, so the source nat IP could get reconfigured as a secondary IP on a nic instead
of it being primary.  This reordering of the IPs on VR reboot caused the VPN to fail because
the source nat IP was no longer the primary IP.  
    So we know that removing all found IPs and then adding them does not work because it changes
the order of the IPs causing the source nat IP to become a secondary IP on the nic.
    The error described in CLOUDSTACK-9811 seems to be a situation where the IP is found on
one nic, but then for some reason the dev which the IP is associated with is changed (I don't
know why this would be happening), causing the index where the IP was found to not be valid
because the IP is actually on a different dev.  
    To know how to fix this correctly, we need to understand why/how an IP can be associated
with one dev (index found) and then get changed to be associated with a different dev.
    We need to find a way to preserve IP order while being able to update the IP configurations.
    @remibergsma do you have any ideas on this?  Anyone else have ideas here?

> 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:
>             Project: CloudStack
>          Issue Type: Bug
>      Security Level: Public(Anyone can view this level - this is the default.) 
>          Components: Virtual Router
>    Affects Versions:
>            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

View raw message