cloudstack-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Angus <>
Subject RE: CS VR on VMware
Date Fri, 18 Jul 2014 14:24:50 GMT
Hi Eric,

What version of the system VM for VMware are you using?


Paul Angus
Cloud Architect
S: +44 20 3603 0540 | M: +447711418784 | T: @CloudyAngus

-----Original Message-----
From: Eric Neumann - AOD []
Sent: 18 July 2014 07:56
To: ''
Subject: RE: CS VR on VMware

so to troubleshoot this further I have created completely fresh install of CloudPlatform
with a fresh vSphere 5.5 environment using distributed switching - no modifications to any
network service offerings, no modifications to anything for that matter.

Created an isolated network and sure enough the problem presents itself; however doesn't appear
with VPC.

The vSphere notes the following error when trying to create the VR:

Task Name: Reconfigure Distributed Switch
Target: cloud.public.3004.0.1-<DVSWITCHNAME> (3004 is the public traffic vlan in this
Status: Cannot complete operation due to concurrent modification by another operation.

The management server log entry i've already posted earlier and just to confirm that again,
as before, the VR is created with 2x public NICs - one in the port group "cloud.public.3004.0.1-<DVSWITCHNAME>"
and one in "cloud.public.3004.200.1-<DVSWITCHNAME>".

And as before, when looking at the VR in CloudPlatform it only shows 3 NICs - Public, Control,
Isolated - as opposed to the actual 4 NICs that the VR is built with.

I'm abandoning this now, but hopefully it'll help someone with troubleshooting whatever bug
is in this area of the system…

From: Eric Neumann - AOD
Sent: Thursday, 17 July 2014 12:32 PM
To: ''
Subject: RE: CS VR on VMware

Thanks Sanjeev,
That's good to know, however in this scenario we only had a single public IP address allocated.
(and only have one public subnet CIDR in this setup)

-----Original Message-----
From: Sanjeev Neelarapu []
Sent: Thursday, 17 July 2014 12:24 PM
Subject: RE: CS VR on VMware

Multiple nics for public traffic will be seen on VR if we use public IP addresses from multiple
CIDRs(multiple subnets in different vlans)
e.g: consume all public IP addresses from one cidr then add another cidr of public ip addresses(in
diff vlan) and use them for any of the SNAT/PF/LB services. In that case one more nic will
be plugged in on VR for public traffic.


-----Original Message-----
From: Eric Neumann - AOD []
Sent: Thursday, July 17, 2014 6:53 AM
To: ''
Subject: RE: CS VR on VMware

And after even further testing, it seems these issues (no source nat entries, additional nics
being created in another public port group) do not occur with a VPC VR, only with a isolated
network VR.

Has anyone encountered anything similar to this?

From: Eric Neumann - AOD
Sent: Thursday, 17 July 2014 12:38 AM
To: ''
Subject: RE: CS VR on VMware

Hi Jayapal,

Thanks very much for the reply.

This is a custom network offering with a default egress policy of deny.

Slight correction from earlier, it appears the default iptable entries are identical between
Xen VR & VMware VR of the same network offering. Also I’ve tested and confirmed that
additional egress policies do successfully get applied to the iptables in both scenarios.

What I found though was that the source nat entry on the VMware VR was missing, so it seems
that isn’t being created for some reason.

I’ve also noticed that the VMware VR had 5 NICs, rather than the 3 NICs I was expecting
– 1xmgmt_network, 1xcloud.guest.916.10000.VDSNAME, 1xcloud.public.3004.10000.VDSNAME and
then an additional 2x in cloud.public.3004.0.VDSNAME which doesn’t seem right.

network_offerings table’s entry of the offering in question -
(just to recap though, the problem seems to present on VMware only, not Xen even though they
share the same network offering…)

the management server log output when creating a new network/VR is here -

The juicy bit seems to be this part (thought I’m not entirely sure what it means… ☺

2014-07-16 14:08:45,297 ERROR [c.c.h.v.r.VmwareResource] (DirectAgent-322:ctx-4b3460ba <<ESXHOST_IP>>)
Failed to find DomR VIF to associate/disassociate IP with.

2014-07-16 14:08:45,297 ERROR [c.c.h.v.r.VmwareResource] (DirectAgent-322:ctx-4b3460ba <<ESXHOST_IP>>)
Unexpected exception: Failed to find DomR VIF
to associate/disassociate IP with. will shortcut rest of IPAssoc commands Failed to find DomR VIF to associate/disassociate
IP with.






                at org.apache.cloudstack.managed.context.ManagedContextRunnable$

                at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$

                at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(

                at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(


                at java.util.concurrent.Executors$

                at java.util.concurrent.FutureTask$Sync.innerRun(


                at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(

                at java.util.concurrent.ScheduledThreadPoolExecutor$

                at java.util.concurrent.ThreadPoolExecutor.runWorker(

                at java.util.concurrent.ThreadPoolExecutor$


Thanks again,



Eric Neumann   Cloud Services Manager

5/19 Wotan Street, Innaloo WA 6018<> <>

-----Original Message-----
From: Jayapal Reddy Uradi []
Sent: Wednesday, 16 July 2014 6:36 PM
To: <<<>>>
Subject: Re: CS VR on VMware

Hi Eric,

Did you created network with default network offering or customer network offering ?

What is egress default policy value (true) in the network offering ?

Can you please send iptables rules on VR, MS server log after VR start and network_offerings,
network table output in



On 16-Jul-2014, at 3:48 PM, Eric Neumann - AOD <<<<>>>>


> Hi All,


> I’ve encountered a strange issue whereby egress firewall rules don’t seem to apply
to any CS VRs that are running on our VMware cluster, whereas any CS VRs running on our XenServer
cluster work as expected (these are in the same and only zone). Even more strangely, port
forwarding and ingress firewall rules do apply correctly in either scenario.


> Has anyone encountered anything similar or has any troubleshooting tips for this? I have
confirmed WAN connectivity, etc. from the VRs console and can see that there’s no matching
entry in the iptables.


> We are running Citrix CloudPlatform


> Any pointers would be greatly appreciated!

> Thanks,

> Eric


Find out more about ShapeBlue and our range of CloudStack related services

IaaS Cloud Design & Build<>
CSForge – rapid IaaS deployment framework<>
CloudStack Consulting<>
CloudStack Infrastructure Support<>
CloudStack Bootcamp Training Courses<>

This email and any attachments to it may be confidential and are intended solely for the use
of the individual to whom it is addressed. Any views or opinions expressed are solely those
of the author and do not necessarily represent those of Shape Blue Ltd or related companies.
If you are not the intended recipient of this email, you must neither take any action based
upon its contents, nor copy or show it to anyone. Please contact the sender if you believe
you have received this email in error. Shape Blue Ltd is a company incorporated in England
& Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated
under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated
in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company
registered by The Republic of South Africa and is traded under license from Shape Blue Ltd.
ShapeBlue is a registered trademark.
View raw message