cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Weller <swel...@ena.com>
Subject Re: KVM plugs public nic twice in non-VPC router
Date Wed, 15 Apr 2015 21:00:48 GMT
Remi,

We haven't experienced exactly what you're describing, but we did have a similar issue that
caused multiple interfaces to be built back when we upgraded to 4.3 from 4.1.1 on KVM.
Have a look at https://issues.apache.org/jira/browse/CLOUDSTACK-6464.
The notes also reference another couple of issues that might have been related.

This particular issue was apparently fixed in 4.4, but nevertheless, it might be worth a look
to see if anything jumps out for you.

- Si

________________________________________
From: Remi Bergsma <RBergsma@schubergphilis.com>
Sent: Tuesday, April 14, 2015 4:19 PM
To: dev@cloudstack.apache.org
Subject: KVM plugs public nic twice in non-VPC router

Hi,

We’re testing KVM and noticed that a virtual router (non-VPC) gets two pubic ip nics plugged.
This is in 4.4.2 when using Open vSwitch on CentOS 7 (advanced zone).

The reason for this, is that the first nic gets plugged by provisioning the nic. Then, a second
nic is plugged that gets the same ip address but a slightly different nic. This is done by
IpAssocCommand. When diving into this, this seems to happen because the StartCommand contains
a IpAssocCommand part with again the public ip. This is probably because this is how we plug
the public nic on VPCs. I think we should remove it for non-VPC routers.

Here you see the second public nic getting plugged:
2015-04-14 21:19:20,099 DEBUG [cloud.agent.Agent] (agentRequest-Handler-5:null) Processing
command: com.cloud.agent.api.routing.IpAssocCommand
2015-04-14 21:19:20,103 DEBUG [kvm.resource.OvsVifDriver] (agentRequest-Handler-5:null) plugging
nic=[Nic:Public-null-vlan://50<public-null-vlan://50>]

Notice the ip-address part of the object is empty.  This leads to this command being ran on
the router:

Apr 14 19:19:20 r-31443-VM cloud: VR config: executing: /opt/cloud/bin/ipassoc.sh -A -s -f
-l 1.2.3.4/24 -c eth3 -g 1.2.3.1 -n

>From a functional perspective this does work, but is not what it should be if you ask
me.

It looks like this issue:
https://issues.apache.org/jira/browse/CLOUDSTACK-4690

But the story about many many nics I cannot reproduce. I do nowever found that associating
extra public ip addresses does not work. The management server reports everything fine, but
I see nothing happening on the router nor the agent on the hypervisor:
2015-04-14 23:09:13,437 DEBUG [cloud.network.IpAddressManagerImpl] (API-Job-Executor-82:ctx-f4953f35
job-534671 ctx-2a536669) Associating ip Ip[1.2.3.5-2] to network Ntwk[a4960690-4a29-445e-b745-881c13bca270|Guest|14]
2015-04-14 23:09:13,449 DEBUG [cloud.network.IpAddressManagerImpl] (API-Job-Executor-82:ctx-f4953f35
job-534671 ctx-2a536669) Successfully associated ip
address 1.2.3.5 to network Ntwk[a4960690-4a29-445e-b745-881c13bca270|Guest|14]

Question:
Does anyone else with KVM running see this behaviour? Or am I missing something?

Thanks,
Remi


Mime
View raw message