Review Request 26263: CLOUDSTACK-7539: [S3] Parallel deployment makes reference count of a cache in nfs secondary staging store negative(-1)

[Hiroki Ohashi]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/26263/
---

Review request for cloudstack, edison su and Min Chen.


Summary (updated)
-

CLOUDSTACK-7539: [S3] Parallel deployment makes reference count of a cache in 
nfs secondary staging store negative(-1)


Bugs: CLOUDSTACK-7539
https://issues.apache.org/jira/browse/CLOUDSTACK-7539


Repository: cloudstack-git


Description (updated)
---

Root causes of CLOUDSTACK-7539 are below.

a. createCacheObject() method lacks mutual exclusion. After calling
   this method, threads check cache existence but the procedure is not
   atomic. So, other threads may call this method and decide to create
   a cache in spite of cache copy being in progress.

b. createCacheObject() method ignores states except READY when it
   checks cache existence. Then, it is considered cache doesn't exist
   in spite of cache copy being in progress.

c. When multiple cache entries about a same image are in a database,
   threads may get a wrong cache entry because of incorrect search
   condition that randomly chooses one entry from entries that have
   same template id. As a result of this retrieval, reference counter
   of the cache probably go negative. (I'm not sure about this
   behavior but I suspect CloudStack behaves like this.)

These behaviors make cache state incorrect and inconsistent.

For fixing this bug, I modified cache creation behavior when no cache
is on NFS Secondary Staging Store(SSS). As sequential deployment
functions so far, I think parallel deployment works well when it is
managed like sequential deployment.

Fixed points are below. These are for cause a. and b., not including
fix for cause c.

1. Protect critical section between cache search and allocation by lock.

   When management server threads reach createCacheObject() method,
   threads get lock at first and check cache existence. In case that no
   cache is on NFS SSS, one thread sends a request for creating cache.
   In other case, threads wait for completion of creating cache not to
   duplicate same image.

2. Add several condition check for cache state.

   If a thread is creating a cache of an image, other threads mustn't
   send no additional request for the same image. Therefore, threads have
   to consider whether a copy request should be issued by those state
   check.


Diffs (updated)
-

  
engine/storage/cache/src/org/apache/cloudstack/storage/cache/manager/StorageCacheManagerImpl.java
 7c74729 

Diff: https://reviews.apache.org/r/26263/diff/


Testing (updated)
---

I tested deployment of two instances at almost the same time. Results
are below.

- Succeed in deployment of two instances.
- No database cache entries are duplicated.
- No duplicated images are on NFS SSS.
- Reference counter never goes to -1.


Thanks,

Hiroki Ohashi

[MERGE] virtual network appliance manager refactorring

[Daan Hoogland]

H,

I just pushed a huge branch with work that my colleagues did [1]. It is
prerequisite to adding redundancy to vpc routers. please take it into
account when doing anything with virtual router functionality as it
addresses a lot of the way we work with configuring those. Merging will
have to wait of course but for any related work I'd advice to use it as
starting point to be joined in the merge later on.

​It will be followed first by refactorings in the virtual routing resource
​and the actual on board router scripts and next by the code to add
redundancy to the vpc version of the router.

​thanks,​

​[1] https://github.com/apache/cloudstack/tree/vpc-refactor​

-- 
Daan

RE: Shellshock

[Adrian Lewis]

I still think that patching bash is the best option. There are a load of
scripts on the system vm that explicitly use bash (/opt/cloud/bin for
example) which take input from the management server so you'd need to
audit all of the input validation rules on the API (maybe it's safe
already). Bear in mind that for a public cloud, legitimate users cannot be
assumed to be trusted. There is also a way to exploit DNSMasq simply by
supplying malicious options in a DHCP request on a client machine. This
does rely on a specific setting in the DNSMasq config which is not set by
default as far as I'm aware so that should at least be safe until someone
decides to use the feature. My point is that simply scanning the system VM
with a tool designed for web servers will help but will only test a
relatively small percentage of potential attack vectors.

These are just a couple of potential attack vectors that I've identified
and I wouldn't have the first clue about programming and have very limited
Linux experience. Surely this is a ticking timebomb until bash is patched?
I'm slightly concerned that so few people appear to care about this. Is
anyone running commercial offerings based on CS concerned about this and
the corresponding compliance issues it raises? Both Amazon and Rackspace
took fairly rapid (and disruptive) action over XSA-108 which has an almost
trivial impact compared with shellshock.

The only solution I can think of is to 'apt-get update bash' on every
system VM but clearly these get fired up dynamically. Is it possible to
boot the template, make modifications and then use as a replacement system
VM? Are there processes that happen on boot that only happen once and
therefore need resetting to recreate the template?



-Original Message-
From: Santhosh Edukulla [mailto:santhosh.eduku...@citrix.com]
Sent: 02 October 2014 23:10
To: dev@cloudstack.apache.org
Subject: RE: Shellshock

We may use the below scanner to identify this vulnerability.  One of our
ex-colleague has written it,  its a remote, network scanner and available
as free download.

http://blog.crowdstrike.com/crowdstrike-shellshock-scanner/

Seems configurable  with custom paths. Please check the note at the end.

Regards,
Santhosh

From: Demetrius Tsitrelis [demetrius.tsitre...@citrix.com]
Sent: Wednesday, October 01, 2014 1:59 PM
To: 
Subject: RE: Shellshock

Actually, I am not sure.  Only the env.cgi script is loaded and, while the
other scripts are in perl, there is nothing in the video which shows the
source for the env.cgi script so it may not be perl.

-Original Message-
From: Demetrius Tsitrelis [mailto:demetrius.tsitre...@citrix.com]
Sent: Wednesday, October 01, 2014 10:52 AM
To: 
Subject: RE: Shellshock

Interestingly this video shows attack against a perl script...
https://www.youtube.com/watch?v=ArEOVHQu9nk

-Original Message-
From: Demetrius Tsitrelis [mailto:demetrius.tsitre...@citrix.com]
Sent: Monday, September 29, 2014 6:13 PM
To: 
Subject: RE: Shellshock

http://systemvm-public-ip/cgi-bin/ipcalc is a perl script.

-Original Message-
From: Sheng Yang [mailto:sh...@yasker.org]
Sent: Monday, September 29, 2014 5:21 PM
To: 
Subject: Re: Shellshock

http://systemvm-public-ip/cgi-bin/ipcalc is NOT a bash script, so it's
normal that it cannot be exploited.

--Sheng

On Fri, Sep 26, 2014 at 1:57 PM, Demetrius Tsitrelis <
demetrius.tsitre...@citrix.com> wrote:

> Do you mean you tried setting the USER_AGENT like in
> https://community.qualys.com/blogs/securitylabs/2014/09/25/qualysguard
> -remote-detection-for-bash-shellshock
> ?
>
>
> -Original Message-
> From: Ian Duffy [mailto:i...@ianduffy.ie]
> Sent: Friday, September 26, 2014 6:56 AM
> To: CloudStack Dev
> Subject: Re: Shellshock
>
> Tried this against the latest system vms built on Jenkins.
>
> Didn't get a successful exploited response. Tested against
> http://systemvm
> - public-ip/cgi-bin/ipcalc
> On 25 Sep 2014 16:56, "Abhinandan Prateek"  wrote:
>
> >
> > After heart bleed we are Shell shocked
> > http://www.bbc.com/news/technology-29361794 !
> > It may not affect cloudstack directly as it is a vulnerability that
> > affects bash, and allows the attacker to take control of the system
> > running bash shell.
> >
> > -abhi
>

Re: [MERGE] virtual network appliance manager refactorring

[Rohit Yadav]

Hi Daan,

Can you create a Github PR, it’s would be much easier to review the diffs. 
Thanks.

On 03-Oct-2014, at 1:22 pm, Daan Hoogland  wrote:
> H,
>
> I just pushed a huge branch with work that my colleagues did [1]. It is
> prerequisite to adding redundancy to vpc routers. please take it into
> account when doing anything with virtual router functionality as it
> addresses a lot of the way we work with configuring those. Merging will
> have to wait of course but for any related work I'd advice to use it as
> starting point to be joined in the merge later on.
>
> ​It will be followed first by refactorings in the virtual routing resource
> ​and the actual on board router scripts and next by the code to add
> redundancy to the vpc version of the router.
>
> ​thanks,​
>
> ​[1] https://github.com/apache/cloudstack/tree/vpc-refactor​
>
> --
> Daan

Regards,
Rohit Yadav
Software Architect, ShapeBlue
M. +41 779015219 | rohit.ya...@shapeblue.com
Blog: bhaisaab.org | Twitter: @_bhaisaab



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.

Re: [EVENT] CloudStack Conference

[Erik Weber]

Any info on number of registrations?

-- 
Erik

On Tue, Sep 30, 2014 at 5:23 PM, sebgoa  wrote:

>  Hi folks,
>
> CloudStack conference in Budapest, Nov 19-21 is coming up fast.
>
> Registration is open:
>
>
> http://events.linuxfoundation.org/events/cloudstack-collaboration-conference-europe/attend/register
>
> And we of course have a great schedule with tutorials, talks, keynotes and
> poster.
>
>
> http://events.linuxfoundation.org/events/cloudstack-collaboration-conference-europe/program/schedule
>
> Looking forward to seeing you all there,
>
> Cheers,
>
> -Sebastien
>

RE: Shellshock

[Alex Brett]

On 03 October 2014 13:52, Adrian Lewis [adr...@alsiconsulting.co.uk] wrote:
> The only solution I can think of is to 'apt-get update bash' on every
> system VM but clearly these get fired up dynamically. Is it possible to
> boot the template, make modifications and then use as a replacement system
> VM? Are there processes that happen on boot that only happen once and
> therefore need resetting to recreate the template?

This isn't a quick fix, so not suitable for this specific issue, but something 
I've wondered for a while is rather than keep having to build new system VM 
templates for every small change, would we be better integrating a tool such as 
Puppet / Chef, so we can bring a system VM 'up to date' when it boots, as long 
as it's the right 'base'.

What I'm thinking here (using Puppet terminology as that's what I'm familiar 
with, but could be any similar mechanism or even just a simple script) is when 
the system VM loads up, it connects to the management server and retrieves a 
manifest, which it then applies. That manifest would specify:
 - Packages to update (including if necessary any apt/yum repo information)
 - Config files to put in place
 - Anything else required like starting any services etc

While it would slightly delay the boot process, it would ensure that on e.g. 
upgrade, you don't have to immediately replace your system VM template unless a 
substantial change (e.g. base system VM distro / partition layout) has been 
made. You could still bring in an updated template to speed things up, but it 
would be far less urgent to do so...

Any thoughts on this anybody?

Alex

Re: [MERGE] virtual network appliance manager refactorring

[Karl Harris]

Daan,

Is it safe to assume that the most of the refactoring work mentioned
(pushed) in your email is outlined in CLOUDSTACK-7143?

Karl


On Fri, Oct 3, 2014 at 7:22 AM, Daan Hoogland 
wrote:

> H,
>
> I just pushed a huge branch with work that my colleagues did [1]. It is
> prerequisite to adding redundancy to vpc routers. please take it into
> account when doing anything with virtual router functionality as it
> addresses a lot of the way we work with configuring those. Merging will
> have to wait of course but for any related work I'd advice to use it as
> starting point to be joined in the merge later on.
>
> ​It will be followed first by refactorings in the virtual routing resource
> ​and the actual on board router scripts and next by the code to add
> redundancy to the vpc version of the router.
>
> ​thanks,​
>
> ​[1] https://github.com/apache/cloudstack/tree/vpc-refactor​
>
> --
> Daan
>



-- 
Karl O. Harris
Cloud Software Engineer
Sungard Availability Services
Office: 215-446-1772
Cell: 215-264-1855
karl.har...@sungardas.com

Re: Shellshock

[Logan Barfield]

>From a service provider perspective I would agree that this issue needs to
be addressed as soon as possible.  In the short term it would make sense
for CloudStack to release a patched SystemVM template and upgrade
instructions.  In the long term I think the better option would be to allow
the templates to be patched more easily (i.e. make changes and save the
template).


Thank You,

Logan Barfield
Tranquil Hosting

On Fri, Oct 3, 2014 at 10:03 AM, Alex Brett  wrote:

> On 03 October 2014 13:52, Adrian Lewis [adr...@alsiconsulting.co.uk]
> wrote:
> > The only solution I can think of is to 'apt-get update bash' on every
> > system VM but clearly these get fired up dynamically. Is it possible to
> > boot the template, make modifications and then use as a replacement
> system
> > VM? Are there processes that happen on boot that only happen once and
> > therefore need resetting to recreate the template?
>
> This isn't a quick fix, so not suitable for this specific issue, but
> something I've wondered for a while is rather than keep having to build new
> system VM templates for every small change, would we be better integrating
> a tool such as Puppet / Chef, so we can bring a system VM 'up to date' when
> it boots, as long as it's the right 'base'.
>
> What I'm thinking here (using Puppet terminology as that's what I'm
> familiar with, but could be any similar mechanism or even just a simple
> script) is when the system VM loads up, it connects to the management
> server and retrieves a manifest, which it then applies. That manifest would
> specify:
>  - Packages to update (including if necessary any apt/yum repo information)
>  - Config files to put in place
>  - Anything else required like starting any services etc
>
> While it would slightly delay the boot process, it would ensure that on
> e.g. upgrade, you don't have to immediately replace your system VM template
> unless a substantial change (e.g. base system VM distro / partition layout)
> has been made. You could still bring in an updated template to speed things
> up, but it would be far less urgent to do so...
>
> Any thoughts on this anybody?
>
> Alex
>

[GitHub] cloudstack pull request: Vpc refactor clean for pr

[DaanHoogland]

GitHub user DaanHoogland opened a pull request:

https://github.com/apache/cloudstack/pull/22

Vpc refactor clean for pr

maybe wait with merging untill 4.5 is branched of. On the other hand we cn 
branch below this refatoring as well

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/schubergphilis/cloudstack 
vpc-refactor-clean-for-PR

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cloudstack/pull/22.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #22


commit 105ee89f47622bff0f6ad6c12af91b5842c4cc48
Author: Antonio Fornie 
Date:   2014-07-03T17:17:26Z

Rules and visitors for Load Balance Rules

Conflicts:
server/src/com/cloud/network/element/VirtualRouterElement.java

commit bca81b05737afe4861b6f588662314af9010ff4f
Author: Antonio Fornie 
Date:   2014-07-10T14:54:01Z

Extract general behavior to Router and Vpc delegates

Conflicts:

server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java

commit 705ced3a84cbdbbe82394f0e2651b9c74207caf1
Author: Antonio Fornie 
Date:   2014-07-11T13:07:35Z

Fix dependency problem. Extract and unify router deployment stuff

Conflicts:

server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java

commit db844438b4bbc97de1fc13113cddd24fde113233
Author: Wilder Rodrigues 
Date:   2014-07-13T12:34:23Z

Adding Firewall Rules to comply with the Visitor pattern implementation; 
refactoring the applyRules so we can reuse it.

Conflicts:
server/src/com/cloud/network/rules/LoadBalancingRules.java
server/src/com/cloud/network/topology/AdvancedNetworkVisitor.java
server/src/com/cloud/network/topology/BasicNetworkTopology.java
server/src/com/cloud/network/topology/NetworkTopology.java

commit 5f5bbe1988613e5ced9943fef2125166ce7eb447
Author: Wilder Rodrigues 
Date:   2014-07-14T09:34:48Z

changing accessor modifier in instance variables

commit b56b62b9d4db404c10980ab93ac3d6845177863e
Author: Wilder Rodrigues 
Date:   2014-07-14T09:52:51Z

fixing checkstyles

Conflicts:
server/src/com/cloud/network/topology/AdvancedNetworkVisitor.java
server/src/com/cloud/network/topology/BasicNetworkTopology.java

commit 1365acd2009dc44e395aab440c60a2a945aca1d4
Author: Wilder Rodrigues 
Date:   2014-07-14T14:20:28Z

finished firewall rules and load balancing rules; fixed all the injection 
problems; added VirtualMachineManager to the appliance factory to be injected.

Conflicts:
server/src/com/cloud/network/element/VirtualRouterElement.java

server/src/com/cloud/network/router/NEWVirtualNetworkApplianceManagerImpl.java
server/src/com/cloud/network/topology/BasicNetworkTopology.java

commit 08cf6b11a18d6c1ddcef3341e31114020257c0d0
Author: Daan Hoogland 
Date:   2014-07-14T15:50:27Z

TODO

commit 00f39e6b51860a00d6fc756e97ba54293c2c7985
Author: Wilder Rodrigues 
Date:   2014-07-14T17:36:29Z

adding static nat rules. Deploying new VMs is not working due to the 
appliance refactory, will check the changes with Antonio tomorrow.

Conflicts:
server/src/com/cloud/network/element/VirtualRouterElement.java
server/src/com/cloud/network/topology/AdvancedNetworkVisitor.java

commit 7b59dce792fabab00728a888c1acd43d8fd35943
Author: Wilder Rodrigues 
Date:   2014-07-15T07:23:26Z

we have to check if VPC is null bfore calling it. VPC is not used in gest 
networks, so deploying a new VM was broken.

commit 6188adb9702a2001bd9f53bacf1eeccea57de7b7
Author: Antonio Fornie 
Date:   2014-07-15T09:06:44Z

Fix offering setup

commit 3d16a407c97d877b96d765bb6dd0cade211e976b
Author: Antonio Fornie 
Date:   2014-07-15T09:54:58Z

Temporary put state info in a state object

commit 91dfad4a9789bf00ce89ee396964c2d003631202
Author: Wilder Rodrigues 
Date:   2014-07-15T07:38:21Z

adding apache license headers

commit 5b60394a3a0d3a373094cdae91640c71d223
Author: Wilder Rodrigues 
Date:   2014-07-15T08:59:42Z

adding Ip Association and VPN Rules

Conflicts:
server/src/com/cloud/network/topology/AdvancedNetworkVisitor.java
server/src/com/cloud/network/topology/BasicNetworkTopology.java
server/src/com/cloud/network/topology/NetworkTopologyVisitor.java

commit 0a08829153d0911b2231b77b88a8c40365504415
Author: Daan Hoogland 
Date:   2014-07-15T09:28:49Z

package rename

Conflicts:
server/src/com/cloud/network/rules/DhcpEntryRules.java
server/src/com/cloud/network/rules/DhcpSubNetRules.java

commit d306dfc194d5913e20642af13c26817d7b11fb2e
Author: Antonio Fornie 
Date:   2014-07-15T16:52:54Z

Unify and encapsulate deployment flow methods and params

Conflicts:

server/src/com/cloud/netwo

Re: [MERGE] virtual network appliance manager refactorring

[Daan Hoogland]

One of us will create e new pr once master is ready for merge. The
functionality hasn't changed since the last pr.  I've created one anyhow.
better not pull it in ;)

On Fri, Oct 3, 2014 at 2:56 PM, Rohit Yadav 
wrote:

> Hi Daan,
>
> Can you create a Github PR, it’s would be much easier to review the diffs.
> Thanks.
>
> On 03-Oct-2014, at 1:22 pm, Daan Hoogland  wrote:
> > H,
> >
> > I just pushed a huge branch with work that my colleagues did [1]. It is
> > prerequisite to adding redundancy to vpc routers. please take it into
> > account when doing anything with virtual router functionality as it
> > addresses a lot of the way we work with configuring those. Merging will
> > have to wait of course but for any related work I'd advice to use it as
> > starting point to be joined in the merge later on.
> >
> > ​It will be followed first by refactorings in the virtual routing
> resource
> > ​and the actual on board router scripts and next by the code to add
> > redundancy to the vpc version of the router.
> >
> > ​thanks,​
> >
> > ​[1] https://github.com/apache/cloudstack/tree/vpc-refactor​
> >
> > --
> > Daan
>
> Regards,
> Rohit Yadav
> Software Architect, ShapeBlue
> M. +41 779015219 | rohit.ya...@shapeblue.com
> Blog: bhaisaab.org | Twitter: @_bhaisaab
>
>
>
> Find out more about ShapeBlue and our range of CloudStack related services
>
> IaaS Cloud Design & Build<
> http://shapeblue.com/iaas-cloud-design-and-build//>
> CSForge – rapid IaaS deployment framework
> CloudStack Consulting
> CloudStack Infrastructure Support<
> http://shapeblue.com/cloudstack-infrastructure-support/>
> CloudStack Bootcamp Training Courses<
> http://shapeblue.com/cloudstack-training/>
>
> 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.
>



-- 
Daan

Re: [Agent] SS VM doesn't connect to the host agent

[Ove Ewerlid]

On 10/03/2014 06:54 AM, Wilder Rodrigues wrote:

SSVM => Agent communication is coming UP again.


Still seeing the connection issue for SSVM/ConsoleSVM.

What systemvm version are you using?

We are using the latest build for master from here;
 http://jenkins.buildacloud.org/job/build-systemvm64-master/

The management head logs this when SSVM/ConsoleSVM attempts to connect;

2014-10-03 17:40:29,443 DEBUG [c.c.a.m.AgentManagerImpl] 
(AgentConnectTaskPool-1777:ctx-a52efbaa) Failed to handle host 
connection: java.lang.ClassCastException: 
com.cloud.agent.api.StartupProxyCommand cannot be cast to 
com.cloud.agent.api.StartupRoutingCommand
2014-10-03 17:40:29,565 DEBUG [c.c.a.m.AgentManagerImpl] 
(AgentConnectTaskPool-1778:ctx-33226ba7) Failed to handle host 
connection: java.lang.ClassCastException: 
com.cloud.agent.api.StartupSecondaryStorageCommand cannot be cast to 
com.cloud.agent.api.StartupRoutingCommand


Environment is updated OEL65 for management head and hypervisors, 
installed from RPMs built from master as of a couple of hours ago.

ACS441 and earlier works in the environment.

Ove


I already created an Advanced Zone (simulator) and I'm now running the 69 
Marvin smoke tests again it: VMs being created; etc..

I'm happy again. When both Advanced and Basic zones have been tested against 
both Simulator and XenServer, I will create my PR and send the details about 
the changes to the community for approval.

Cheers,
Wilder

-Original Message-
From: Wilder Rodrigues
Sent: Friday, October 03, 2014 6:27 AM
To: ; 'w...@widodh.nl'
Cc: int-toolkit
Subject: RE: [Agent] SS VM doesn't connect to the host agent

Hi Wido,

Could not do much last night due to other issues.

Just got 8 new commits:

97768b2 CLOUDSTACK-7668: UI > When UI is loaded the first time, sometimes a blank 
screen instead of a login screen shows > fix it by declaring the variables 
beforehand.
3201251 ccp should not check public ip resource when deploy a vm on shared network 
53d5e8a CLOUDSTACK-7668: UI > When UI is loaded the first time, sometimes a 
blank screen instead of a login screen shows. Only after clicking Refresh 
button(i.e. loaded again) will the login screen show.
0ef6cd3 Revert "CLOUDSTACK-6650: Reorder Cluster list in deployment planner to 
protect"
53db8c7 Revert "Remove adding implicit tags in DB schema so that management server 
starts, original commit 39fe766c2b6fb6edd4c1 needs review"
dfe2bfe Merge branch 'master' of 
https://git-wip-us.apache.org/repos/asf/cloudstack
597d3d7 Remove adding implicit tags in DB schema so that management server 
starts, original commit 39fe766c2b6fb6edd4c1 needs review
0646588 CLOUDSTACK-7645: [UI] Fixing incorrect labels, including instances of 
"???label.*???"

I don't see anything about SSVM, but I already rebased my branch and will give 
it a try.

In case it won't work, I will create a bug, try to fix it and send a pull 
request separately.

Will keep you updated.

Cheers,
Wilder


-Original Message-
From: Wilder Rodrigues
Sent: Thursday, October 02, 2014 3:09 PM
To: 
Cc: int-toolkit
Subject: Re: [Agent] SS VM doesn't connect to the host agent

Thanks for the reply, Wido.

I have to pick up my daughter, but will try the telnet asap.

Cheers,
Wilder

Sent from my iPhone


On 02 Oct 2014, at 14:04, "Wido den Hollander"  wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On 10/02/2014 01:55 PM, Wilder Rodrigues wrote:
Hi all,

I have been busy trying to identify why is the SS VM connection to
the host agent broken. Could anyone please give me a clue?


Well, I don't have a clue, but I saw this on master as well yesterday.

What happens if you telnet to port 8250 on the management server? Does
that work or does it close the connection as soon as you connect?

Wido


We have a massive Pull Request to be sent. This morning everything
was working, tested with Basic/Advanced zones with both Simulator and
XenServer. All smoke tests passing (69!). After I rebased and got 26
commits from Master and went testing everything again, just started
facing this problem.

Without agent connection there are no templates ready. So, I cannot
do anything.

In order to prove that the problem was introduced by one of the 26
commits I got this morning, I checkout a branch I have - before the
rebased - and tested it again. All fine! When I get the new branch
- rebased with the master's 26 commits - agent connection is broken.

Unfortunately there is no stack trace/complains... it simply doesn't
connect.

Does anyone have any idea? I really appreciate if someone can give me
a clue.

With kind regards, Wilder


-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJULT9BAAoJEAGbWC3bPspCgpcQAJNPPbO1UH6YRwQvIRWu8WiY
q2KAJy4fml2WfQxMDa+vE5GDFYEO2Os2asCCH0dxv9g/a+qGdTIQW1BrN2cSvWUo
sGmJFEpx3by7rFB2iFWclHq0Be1xx8yeuFDbYRE4FxCEwpbWbnC3tTPaN3Kwx3eG
3iSGNsCu50zq+apaiKVCeDwowoPax6abHF96eXKc10/X6w5xNKm+YXSOufMuOYtW
tKX/KS8RvZo3OY27Dpu8O6myNxgq/H26qdnopaQpmsVFEt+bdn5hX7XyIf19t1B/
nyLxaYPxT

Re: [MERGE] virtual network appliance manager refactorring

[David Nalley]

As noted in your PR, please don't merge this immediately into master.
We're in feature freeze, and master is currently 4.5

Thanks,

--David

On Fri, Oct 3, 2014 at 7:22 AM, Daan Hoogland  wrote:
> H,
>
> I just pushed a huge branch with work that my colleagues did [1]. It is
> prerequisite to adding redundancy to vpc routers. please take it into
> account when doing anything with virtual router functionality as it
> addresses a lot of the way we work with configuring those. Merging will
> have to wait of course but for any related work I'd advice to use it as
> starting point to be joined in the merge later on.
>
> It will be followed first by refactorings in the virtual routing resource
> and the actual on board router scripts and next by the code to add
> redundancy to the vpc version of the router.
>
> thanks,
>
> [1] https://github.com/apache/cloudstack/tree/vpc-refactor
>
> --
> Daan

Re: [MERGE] virtual network appliance manager refactorring

[Daan Hoogland]

H Karl, no it isn't. This ticket is just for the systemvm template creation.


On Fri, Oct 3, 2014 at 4:42 PM, Karl Harris 
wrote:

> Daan,
>
> Is it safe to assume that the most of the refactoring work mentioned
> (pushed) in your email is outlined in CLOUDSTACK-7143?
>
> Karl
>
>
> On Fri, Oct 3, 2014 at 7:22 AM, Daan Hoogland 
> wrote:
>
> > H,
> >
> > I just pushed a huge branch with work that my colleagues did [1]. It is
> > prerequisite to adding redundancy to vpc routers. please take it into
> > account when doing anything with virtual router functionality as it
> > addresses a lot of the way we work with configuring those. Merging will
> > have to wait of course but for any related work I'd advice to use it as
> > starting point to be joined in the merge later on.
> >
> > ​It will be followed first by refactorings in the virtual routing
> resource
> > ​and the actual on board router scripts and next by the code to add
> > redundancy to the vpc version of the router.
> >
> > ​thanks,​
> >
> > ​[1] https://github.com/apache/cloudstack/tree/vpc-refactor​
> >
> > --
> > Daan
> >
>
>
>
> --
> Karl O. Harris
> Cloud Software Engineer
> Sungard Availability Services
> Office: 215-446-1772
> Cell: 215-264-1855
> karl.har...@sungardas.com
>



-- 
Daan

Re: [MERGE] virtual network appliance manager refactorring

[Daan Hoogland]

yes, and it is good to stress that once again!

On Fri, Oct 3, 2014 at 6:00 PM, David Nalley  wrote:

> As noted in your PR, please don't merge this immediately into master.
> We're in feature freeze, and master is currently 4.5
>
> Thanks,
>
> --David
>
> On Fri, Oct 3, 2014 at 7:22 AM, Daan Hoogland 
> wrote:
> > H,
> >
> > I just pushed a huge branch with work that my colleagues did [1]. It is
> > prerequisite to adding redundancy to vpc routers. please take it into
> > account when doing anything with virtual router functionality as it
> > addresses a lot of the way we work with configuring those. Merging will
> > have to wait of course but for any related work I'd advice to use it as
> > starting point to be joined in the merge later on.
> >
> > It will be followed first by refactorings in the virtual routing resource
> > and the actual on board router scripts and next by the code to add
> > redundancy to the vpc version of the router.
> >
> > thanks,
> >
> > [1] https://github.com/apache/cloudstack/tree/vpc-refactor
> >
> > --
> > Daan
>



-- 
Daan

ACTION Required from Cloud Operators [realhostip]: Your users may lose console access to their CloudStack VMs soon!

[Chiradeep Vittal]

Hi

The realhostip.com DNS resolver will be turned off imminently. This is the
default resolver used by the Console in releases 4.2 and below to resolve
the IP of the console proxy VM. Once the DNS resolver is turned off, IF
YOU HAVE NOT taken action to not replace the default, console access will
not work.


See these blog posts:
https://blogs.apache.org/cloudstack/entry/realhostip_service_is_being_retir
ed
https://blogs.apache.org/cloudstack/entry/cloudstack_s_realhostip_service_t
o

http://shapeblue.com/cloudstack/retirement-of-the-realhostip-com-service/


Please avoid inconvenience to your users and make the required changes
immediately.

‹
Chiradeep

Re: Can't launch VMs

[Chiradeep Vittal]

Not sure what is a “basic zone no security groups”. Check your vlan table to 
see if there has been any allocation of vlans?

From: Carlos Reategui mailto:create...@gmail.com>>
Reply-To: "dev@cloudstack.apache.org" 
mailto:dev@cloudstack.apache.org>>, 
"car...@reategui.com" 
mailto:car...@reategui.com>>
Date: Thursday, October 2, 2014 at 3:48 PM
To: "dev@cloudstack.apache.org" 
mailto:dev@cloudstack.apache.org>>
Subject: Fwd: Can't launch VMs

Hi devs,
Daan suggested I check with you all regarding this email I sent to the
users list.

He said "the line of code that breaks expects a uri for a vlan", However I
am using basic networking and I don't know where to add a vlan in that setup.
He also said this was a known issue.  Hopefully one of you all knows a fix.

This deployment had been working fine.  Originally a 4.1, upgraded to 4.2.1
and more recently to 4.3 and 4.3.1.  It was definitely working under 4.2.1
and I though it had been working under 4.3 as well but I am not sure now.
There is no problem with existing instances.  The problem is when trying to
launch new ones.

Let me know what additional info would be useful.

thank you,
Carlos



-- Forwarded message --
From: Carlos Reategui mailto:create...@gmail.com>>
Date: Mon, Sep 29, 2014 at 4:53 PM
Subject: Can't launch VMs
To: "us...@cloudstack.apache.org" 
mailto:us...@cloudstack.apache.org>>


Following up on my earlier email regarding errors in my logs it appears
things are not as great as I thought.  Trying to launch instances is not
working.  Please help.
thanks,
Carlos

ACS: 4.3.1
Hosts: XenServer 6.2
Network: Basic Shared Network no SG

Things appear ok up until it tries to create the VIF.  Here are the logs:

2014-09-29 16:26:24,816 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgent-235:ctx-7f8db7ac) Seq 2-868943178: Executing request

2014-09-29 16:26:25,003 DEBUG [c.c.h.x.r.CitrixResourceBase]
(DirectAgent-235:ctx-7f8db7ac) 1. The VM i-3-98-VM is in Starting state.

2014-09-29 16:26:25,174 DEBUG [c.c.h.x.r.CitrixResourceBase]
(DirectAgent-235:ctx-7f8db7ac) Created VM
71314961-a1bf-689e-eaec-73b9e3639db8 for i-3-98-VM

2014-09-29 16:26:25,405 DEBUG [c.c.h.x.r.CitrixResourceBase]
(DirectAgent-235:ctx-7f8db7ac) VBD 9297b527-7b1f-600c-0d55-8486a8bd35d7
created for com.cloud.agent.api.to.DiskTO@53d6031b

2014-09-29 16:26:25,509 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgent-399:ctx-73a60525) Seq 2-868943177: Response Received:

2014-09-29 16:26:25,509 DEBUG [c.c.a.t.Request]
(StatsCollector-3:ctx-13616221) Seq 2-868943177: Received:  { Ans: ,
MgmtId: 233845174730255, via: 2, Ver: v1, Flags: 10, {
GetStorageStatsAnswer } }

2014-09-29 16:26:25,512 DEBUG [c.c.a.m.DirectAgentAttache]
(DirectAgent-392:ctx-401c432d) Seq 2-868943179: Executing request

2014-09-29 16:26:25,618 DEBUG [c.c.h.x.r.CitrixResourceBase]
(DirectAgent-235:ctx-7f8db7ac) VBD 6609b989-ec81-10c1-8b00-b1fb1eb3885f
created for com.cloud.agent.api.to.DiskTO@7fbb227a

2014-09-29 16:26:25,658 DEBUG [c.c.a.ApiServlet]
(catalina-exec-12:ctx-a4bf4221) ===START===  172.30.36.159 -- GET
command=queryAsyncJobResult&jobId=f38a8e56-9a85-48aa-9da2-d498d3179634&response=json&sessionkey=UWhJaGdVTH3zXZ9WFdv4EwAlqA4%3D&_=1412033185658

2014-09-29 16:26:25,679 DEBUG [c.c.a.ApiServlet]
(catalina-exec-12:ctx-a4bf4221 ctx-d566be7f) ===END===  172.30.36.159 --
GET
command=queryAsyncJobResult&jobId=f38a8e56-9a85-48aa-9da2-d498d3179634&response=json&sessionkey=UWhJaGdVTH3zXZ9WFdv4EwAlqA4%3D&_=1412033185658

2014-09-29 16:26:25,735 DEBUG [c.c.h.x.r.CitrixResourceBase]
(DirectAgent-235:ctx-7f8db7ac) VBD d47f3673-7dc8-68ff-7eb7-fcd6ba8b0c41
created for com.cloud.agent.api.to.DiskTO@194e84ba

2014-09-29 16:26:25,735 DEBUG [c.c.h.x.r.CitrixResourceBase]
(DirectAgent-235:ctx-7f8db7ac) Creating VIF for i-3-98-VM on nic
[Nic:Guest-172.30.45.143-null]

2014-09-29 16:26:25,834 WARN  [c.c.h.x.r.CitrixResourceBase]
(DirectAgent-235:ctx-7f8db7ac) Catch Exception: class
java.lang.NullPointerException due to java.lang.NullPointerException

java.lang.NullPointerException

at
com.cloud.network.Networks$BroadcastDomainType.getSchemeValue(Networks.java:173)

at
com.cloud.network.Networks$BroadcastDomainType.getValue(Networks.java:228)

at
com.cloud.hypervisor.xen.resource.CitrixResourceBase.getNetwork(CitrixResourceBase.java:1035)

at
com.cloud.hypervisor.xen.resource.CitrixResourceBase.createVif(CitrixResourceBase.java:1088)

at
com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:1718)

at
com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:545)

at
com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:59)

at
com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:216)

a

Re: Can't launch VMs

[Carlos Reátegui]

Thanks for having a look.  Inline...

On Oct 3, 2014, at 11:38 AM, Chiradeep Vittal  
wrote:

> Not sure what is a “basic zone no security groups”.
Basic Zone type with the following Network Offering: 
DefaultSharedNetworkOffering as opposed to the default/first option 
DefaultSharedNetworkOfferingWithSGService.

> Check your vlan table to see if there has been any allocation of vlans?
mysql> select * from vlan;
++--+-+--+---+-++++-+-+--+---+
| id | uuid | vlan_id | vlan_gateway | 
vlan_netmask  | description | vlan_type  | data_center_id | 
network_id | physical_network_id | ip6_gateway | ip6_cidr | ip6_range |
++--+-+--+---+-++++-+-+--+---+
|  1 | 5ebc3075-2946-4be4-9e7a-f32a86e7edfc | vlan://untagged | 172.30.45.1  | 
255.255.255.0 | 172.30.45.100-172.30.45.174 | DirectAttached |  1 | 
   204 | 200 | NULL| NULL | NULL  |
++--+-+--+---+-++++-+-+--+---+
1 row in set (0.00 sec)



> 
> From: Carlos Reategui mailto:create...@gmail.com>>
> Reply-To: "dev@cloudstack.apache.org" 
> mailto:dev@cloudstack.apache.org>>, 
> "car...@reategui.com" 
> mailto:car...@reategui.com>>
> Date: Thursday, October 2, 2014 at 3:48 PM
> To: "dev@cloudstack.apache.org" 
> mailto:dev@cloudstack.apache.org>>
> Subject: Fwd: Can't launch VMs
> 
> Hi devs,
> Daan suggested I check with you all regarding this email I sent to the
> users list.
> 
> He said "the line of code that breaks expects a uri for a vlan", However I
> am using basic networking and I don't know where to add a vlan in that setup.
> He also said this was a known issue.  Hopefully one of you all knows a fix.
> 
> This deployment had been working fine.  Originally a 4.1, upgraded to 4.2.1
> and more recently to 4.3 and 4.3.1.  It was definitely working under 4.2.1
> and I though it had been working under 4.3 as well but I am not sure now.
> There is no problem with existing instances.  The problem is when trying to
> launch new ones.
> 
> Let me know what additional info would be useful.
> 
> thank you,
> Carlos
> 
> 
> 
> -- Forwarded message --
> From: Carlos Reategui mailto:create...@gmail.com>>
> Date: Mon, Sep 29, 2014 at 4:53 PM
> Subject: Can't launch VMs
> To: "us...@cloudstack.apache.org" 
> mailto:us...@cloudstack.apache.org>>
> 
> 
> Following up on my earlier email regarding errors in my logs it appears
> things are not as great as I thought.  Trying to launch instances is not
> working.  Please help.
> thanks,
> Carlos
> 
> ACS: 4.3.1
> Hosts: XenServer 6.2
> Network: Basic Shared Network no SG
> 
> Things appear ok up until it tries to create the VIF.  Here are the logs:
> 
> 2014-09-29 16:26:24,816 DEBUG [c.c.a.m.DirectAgentAttache]
> (DirectAgent-235:ctx-7f8db7ac) Seq 2-868943178: Executing request
> 
> 2014-09-29 16:26:25,003 DEBUG [c.c.h.x.r.CitrixResourceBase]
> (DirectAgent-235:ctx-7f8db7ac) 1. The VM i-3-98-VM is in Starting state.
> 
> 2014-09-29 16:26:25,174 DEBUG [c.c.h.x.r.CitrixResourceBase]
> (DirectAgent-235:ctx-7f8db7ac) Created VM
> 71314961-a1bf-689e-eaec-73b9e3639db8 for i-3-98-VM
> 
> 2014-09-29 16:26:25,405 DEBUG [c.c.h.x.r.CitrixResourceBase]
> (DirectAgent-235:ctx-7f8db7ac) VBD 9297b527-7b1f-600c-0d55-8486a8bd35d7
> created for com.cloud.agent.api.to.DiskTO@53d6031b
> 
> 2014-09-29 16:26:25,509 DEBUG [c.c.a.m.DirectAgentAttache]
> (DirectAgent-399:ctx-73a60525) Seq 2-868943177: Response Received:
> 
> 2014-09-29 16:26:25,509 DEBUG [c.c.a.t.Request]
> (StatsCollector-3:ctx-13616221) Seq 2-868943177: Received:  { Ans: ,
> MgmtId: 233845174730255, via: 2, Ver: v1, Flags: 10, {
> GetStorageStatsAnswer } }
> 
> 2014-09-29 16:26:25,512 DEBUG [c.c.a.m.DirectAgentAttache]
> (DirectAgent-392:ctx-401c432d) Seq 2-868943179: Executing request
> 
> 2014-09-29 16:26:25,618 DEBUG [c.c.h.x.r.CitrixResourceBase]
> (DirectAgent-235:ctx-7f8db7ac) VBD 6609b989-ec81-10c1-8b00-b1fb1eb3885f
> created for com.cloud.agent.api.to.DiskTO@7fbb227a
> 
> 2014-09-29 16:26:25,658 DEBUG [c.c.a.ApiServlet]
> (catalina-exec-12:ctx-a4bf4221) ===START===  172.30.36.159 -- GET
> command=queryAsyncJobResult&jobId=f38a8e56-9a85-48aa-9da2-d498d3179634&response=json&sessionkey=UWhJaGdVTH3zXZ9WFdv4EwAlqA4%3D&_=1412033185658
> 
> 2014-

Re: Can't launch VMs

[Chiradeep Vittal]

Wonder if Daan is talking about
https://issues.apache.org/jira/browse/CLOUDSTACK-4346


As you can see from
https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blob;f=plugins/h
ypervisors/xenserver/src/com/cloud/hypervisor/xenserver/resource/CitrixReso
urceBase.java;h=9313e5673f30e6a70f915258ee78c7e5832399d4;hb=HEAD#l1019 ,
the first check for ³untagged² should¹ve gone through, except that it goes
through and either hits line 1025 instead.
So, check your Œnetworks¹ table and see if the URI is correct.


From:  Carlos Reátegui 
Reply-To:  "dev@cloudstack.apache.org" 
Date:  Friday, October 3, 2014 at 12:15 PM
To:  "dev@cloudstack.apache.org" 
Subject:  Re: Can't launch VMs


Thanks for having a look.  Inline...

On Oct 3, 2014, at 11:38 AM, Chiradeep Vittal
 wrote:

> Not sure what is a ³basic zone no security groups².
Basic Zone type with the following Network Offering:
DefaultSharedNetworkOffering as opposed to the default/first option
DefaultSharedNetworkOfferingWithSGService.

> Check your vlan table to see if there has been any allocation of vlans?
mysql> select * from vlan;
++--+-+
--+---+-++-
---++-+-+--+---
+
| id | uuid | vlan_id |
vlan_gateway | vlan_netmask  | description | vlan_type
 | data_center_id | network_id | physical_network_id | ip6_gateway |
ip6_cidr | ip6_range |
++--+-+
--+---+-++-
---++-+-+--+---
+
|  1 | 5ebc3075-2946-4be4-9e7a-f32a86e7edfc | vlan://untagged |
172.30.45.1  | 255.255.255.0 | 172.30.45.100-172.30.45.174 |
DirectAttached |  1 |204 | 200 | NULL
  | NULL | NULL  |
++--+-+
--+---+-++-
---++-+-+--+---
+
1 row in set (0.00 sec)



> 
> From: Carlos Reategui mailto:create...@gmail.com>>
> Reply-To: "dev@cloudstack.apache.org"
>mailto:dev@cloudstack.apache.org>>,
>"car...@reategui.com"
>mailto:car...@reategui.com>>
> Date: Thursday, October 2, 2014 at 3:48 PM
> To: "dev@cloudstack.apache.org"
>mailto:dev@cloudstack.apache.org>>
> Subject: Fwd: Can't launch VMs
> 
> Hi devs,
> Daan suggested I check with you all regarding this email I sent to the
> users list.
> 
> He said "the line of code that breaks expects a uri for a vlan", However
>I
> am using basic networking and I don't know where to add a vlan in that
>setup.
> He also said this was a known issue.  Hopefully one of you all knows a
>fix.
> 
> This deployment had been working fine.  Originally a 4.1, upgraded to
>4.2.1
> and more recently to 4.3 and 4.3.1.  It was definitely working under
>4.2.1
> and I though it had been working under 4.3 as well but I am not sure now.
> There is no problem with existing instances.  The problem is when trying
>to
> launch new ones.
> 
> Let me know what additional info would be useful.
> 
> thank you,
> Carlos
> 
> 
> 
> -- Forwarded message --
> From: Carlos Reategui mailto:create...@gmail.com>>
> Date: Mon, Sep 29, 2014 at 4:53 PM
> Subject: Can't launch VMs
> To: "us...@cloudstack.apache.org"
>mailto:us...@cloudstack.apache.org>>
> 
> 
> Following up on my earlier email regarding errors in my logs it appears
> things are not as great as I thought.  Trying to launch instances is not
> working.  Please help.
> thanks,
> Carlos
> 
> ACS: 4.3.1
> Hosts: XenServer 6.2
> Network: Basic Shared Network no SG
> 
> Things appear ok up until it tries to create the VIF.  Here are the logs:
> 
> 2014-09-29 16:26:24,816 DEBUG [c.c.a.m.DirectAgentAttache]
> (DirectAgent-235:ctx-7f8db7ac) Seq 2-868943178: Executing request
> 
> 2014-09-29 16:26:25,003 DEBUG [c.c.h.x.r.CitrixResourceBase]
> (DirectAgent-235:ctx-7f8db7ac) 1. The VM i-3-98-VM is in Starting state.
> 
> 2014-09-29 16:26:25,174 DEBUG [c.c.h.x.r.CitrixResourceBase]
> (DirectAgent-235:ctx-7f8db7ac) Created VM
> 71314961-a1bf-689e-eaec-73b9e3639db8 for i-3-98-VM
> 
> 2014-09-29 16:26:25,405 DEBUG [c.c.h.x.r.CitrixResourceBase]
> (DirectAgent-235:ctx-7f8db7ac) VBD 9297b527-7b1f-600c-0d55-8486a8bd35d7
> created for com.cloud.agent.api.to.DiskTO@53d6031b
> 
> 2014-09-29 16:26:25,509 DEBUG [c.c.a.m.DirectAgentAttache]
> (DirectAgent-399:ctx-73a60525) Seq 2-868943177: Response Received:
> 
> 2014-09-29 16:26:25,509 DEBUG [c.c.a.t.Request]
> (StatsCollector-3:ctx-13616221) Seq 2-868943177: Received:  { Ans: ,
> Mg

Re: Can't launch VMs

[Carlos Reátegui]

Don’t know how to “check your Œnetworks¹ table and see if the URI is correct."

Here is my networks table:

mysql> select * from networks;
+-+--+--+--+--+---+---+-+++-+-++---+---+-+---++--+--+---++--+---+++--+-+-+---++-+--+--+-++
| id  | name | uuid | 
display_text | traffic_type | broadcast_domain_type | broadcast_uri 
| gateway | cidr   | mode   | network_offering_id | 
physical_network_id | data_center_id | guru_name | state | 
related | domain_id | account_id | dns1 | dns2 | guru_data | set_fields | 
acl_type | network_domain| reservation_id | guest_type | restart_required | 
created | removed | specify_ip_ranges | vpc_id | ip6_gateway | 
ip6_cidr | network_cidr | display_network | network_acl_id |
+-+--+--+--+--+---+---+-+++-+-++---+---+-+---++--+--+---++--+---+++--+-+-+---++-+--+--+-++
| 200 | NULL | e5a63a7e-69a2-467f-8a5f-9be907c75473 | NULL  
   | Public   | Vlan  | NULL  | 
NULL| NULL   | Static |   1 |
NULL |  1 | PublicNetworkGuru | Setup | 200 | 1 
|  1 | NULL | NULL | NULL  |  0 | NULL | NULL   
   | NULL   | NULL   |0 | 2013-04-30 21:25:41 | 
NULL| 1 |   NULL | NULL| NULL | NULL |  
 1 |   NULL |
| 201 | NULL | 62146c15-3981-486d-a404-91bd264a2c0b | NULL  
   | Management   | Native| NULL  | 
NULL| NULL   | Static |   2 |
NULL |  1 | PodBasedNetworkGuru   | Setup | 201 | 1 
|  1 | NULL | NULL | NULL  |  0 | NULL | NULL   
   | NULL   | NULL   |0 | 2013-04-30 21:25:41 | 
NULL| 0 |   NULL | NULL| NULL | NULL |  
 1 |   NULL |
| 202 | NULL | 45e65367-6945-40eb-a650-345bc5696eb1 | NULL  
   | Control  | LinkLocal | NULL  | 
169.254.0.1 | 169.254.0.0/16 | Static |   3 |
NULL |  1 | ControlNetworkGuru| Setup | 202 | 1 
|  1 | NULL | NULL | NULL  |  0 | NULL | NULL   
   | NULL   | NULL   |0 | 2013-04-30 21:25:41 | 
NULL| 0 |   NULL | NULL| NULL | NULL |  
 1 |   NULL |
| 203 | NULL | fd59f2b4-7db1-4383-9aea-b6ee361f8863 | NULL  
   | Storage  | Native| NULL  | 
NULL| NULL   | Static |   4 |
NULL |  1 | StorageNetworkGuru| Setup | 203 | 1 
|  1 | NULL | NULL | NULL  |  0 | NULL | NULL   
   | NULL   | NULL   |0 | 2013-04-30 21:25:41 | 
NULL| 1 |   NULL | NULL| NULL | NULL |  
 1 |   NULL |
| 204 | guestNetworkForBasicZone | 97ad8dd0-3617-44fa-aa9e-e43c27e0ff79 | 
guestNetworkForBasicZone | Guest| Vlan  | NULL  
| 172.30.45.1 | NULL   | Dhcp   |   7 | 
200 |  1 | DirectPodBasedNetworkGuru | Setup | 204 | 1 
|  1 | NULL | NULL | NULL  |  0 | Domain   | 
cs1cloud.internal | NULL   | Shared |0 | 2013-04-30 
21:25:58 | NULL| 1 |   NULL | NULL| NULL | NULL 
|   1 |   NULL |
+-+--+--+--+--+---+---

Re: Can't launch VMs

[Chiradeep Vittal]

Not really sure. Check your nics table as well
select id, instance_id, network_id, netmask, gateway, ip4_address,
broadcast_uri, mode, state, strategy from nics where network_id=204

It looks like the broadcast_uri is null? Should be vlan://untagged


From:  Carlos Reátegui 
Reply-To:  "dev@cloudstack.apache.org" 
Date:  Friday, October 3, 2014 at 12:48 PM
To:  "dev@cloudstack.apache.org" 
Cc:  Daan Hoogland 
Subject:  Re: Can't launch VMs


Don’t know how to “check your Œnetworks¹ table and see if the URI is
correct."

Here is my networks table:

mysql> select * from networks;
+-+--+--+--
+--+---+---
+-+++-+
-++---+---+
-+---++--+--+---++-
-+---+++--+
-+-+---++-+
--+--+-++
| id  | name | uuid |
display_text | traffic_type | broadcast_domain_type |
broadcast_uri | gateway | cidr   | mode   |
network_offering_id | physical_network_id | data_center_id | guru_name
| state | related | domain_id | account_id | dns1 | dns2 |
guru_data | set_fields | acl_type | network_domain| reservation_id |
guest_type | restart_required | created | removed |
specify_ip_ranges | vpc_id | ip6_gateway | ip6_cidr | network_cidr |
display_network | network_acl_id |
+-+--+--+--
+--+---+---
+-+++-+
-++---+---+
-+---++--+--+---++-
-+---+++--+
-+-+---++-+
--+--+-++
| 200 | NULL | e5a63a7e-69a2-467f-8a5f-9be907c75473 |
NULL | Public   | Vlan  | NULL
 | NULL| NULL   | Static |   1 |
 NULL |  1 | PublicNetworkGuru | Setup |
200 | 1 |  1 | NULL | NULL | NULL  |  0 | NULL
| NULL  | NULL   | NULL   |0 |
2013-04-30 21:25:41 | NULL| 1 |   NULL | NULL|
NULL | NULL |   1 |   NULL |
| 201 | NULL | 62146c15-3981-486d-a404-91bd264a2c0b |
NULL | Management   | Native| NULL
 | NULL| NULL   | Static |   2 |
 NULL |  1 | PodBasedNetworkGuru   | Setup |
201 | 1 |  1 | NULL | NULL | NULL  |  0 | NULL
| NULL  | NULL   | NULL   |0 |
2013-04-30 21:25:41 | NULL| 0 |   NULL | NULL|
NULL | NULL |   1 |   NULL |
| 202 | NULL | 45e65367-6945-40eb-a650-345bc5696eb1 |
NULL | Control  | LinkLocal | NULL
 | 169.254.0.1 | 169.254.0.0/16 | Static |   3 |
 NULL |  1 | ControlNetworkGuru| Setup |
202 | 1 |  1 | NULL | NULL | NULL  |  0 | NULL
| NULL  | NULL   | NULL   |0 |
2013-04-30 21:25:41 | NULL| 0 |   NULL | NULL|
NULL | NULL |   1 |   NULL |
| 203 | NULL | fd59f2b4-7db1-4383-9aea-b6ee361f8863 |
NULL | Storage  | Native| NULL
 | NULL| NULL   | Static |   4 |
 NULL |  1 | StorageNetworkGuru| Setup |
203 | 1 |  1 | NULL | NULL | NULL  |  0 | NULL
| NULL  | NULL   | NULL   |0 |
2013-04-30 21:25:41 | NULL| 1 |   NULL | NULL|
NULL | NULL |   1 |   NULL |
| 204 | guestNetworkForBasicZone | 97ad8dd0-3617-44fa-aa9e-e43c27e0ff79 |
guestNetworkForBasicZone | Guest| Vlan  | NULL
 | 172.30.45.1 | NULL   | Dhcp   |   7 |
  200 |  1 | DirectPodBasedNetworkGuru | Setup |
204 | 1 |  1 | NULL | NULL | NULL  |  0 |
Domain   | cs1cloud.intern

Re: Can't launch VMs

[Carlos Reátegui]

Hmm.  I just checked another deployment I did with 4.4.0 using the same zone 
type and network offering and it has the broadcast_uri set to vlan://untagged.

I also checked previous backups from older versions (4.10 and 4.2.1) and in all 
of those the broadcast_uri was blank.  I am wondering if this is a bug in the 
upgrade scripts. 

I updated network 204 and set the broadcast_uri and now I am able to start new 
instances.

thank you for your help!

I am including my nics table just in case you spot something else out of the 
ordinary.

mysql> select id, instance_id, network_id, netmask, gateway, ip4_address, 
broadcast_uri, mode, state, strategy from nics where network_id=204 order by 
ip4_address;
+-+-++---+-+---+-+--+--+-+
| id  | instance_id | network_id | netmask   | gateway | ip4_address   
| broadcast_uri   | mode | state| strategy|
+-+-++---+-+---+-+--+--+-+
|  60 |  52 |204 | NULL  | NULL| NULL  
| NULL| Dhcp | Deallocating | Start   |
|  64 |  53 |204 | NULL  | NULL| NULL  
| NULL| Dhcp | Deallocating | Start   |
|  68 |  54 |204 | NULL  | NULL| NULL  
| NULL| Dhcp | Deallocating | Start   |
|  72 |  55 |204 | NULL  | NULL| NULL  
| NULL| Dhcp | Deallocating | Start   |
|  76 |  56 |204 | NULL  | NULL| NULL  
| NULL| Dhcp | Deallocating | Start   |
|  30 |  21 |204 | 255.255.255.0 | 172.30.45.1 | 172.30.45.100 
| vlan://untagged | Dhcp | Deallocating | Start   |
|  32 |  23 |204 | 255.255.255.0 | 172.30.45.1 | 172.30.45.100 
| vlan://untagged | Dhcp | Deallocating | Start   |
|  43 |  34 |204 | 255.255.255.0 | 172.30.45.1 | 172.30.45.100 
| vlan://untagged | Dhcp | Deallocating | Start   |
|  47 |  38 |204 | 255.255.255.0 | 172.30.45.1 | 172.30.45.100 
| vlan://untagged | Dhcp | Reserved | Start   |
|   1 |   1 |204 | 255.255.255.0 | 172.30.45.1 | 172.30.45.101 
| vlan://untagged | Dhcp | Deallocating | Start   |
|  13 |   5 |204 | 255.255.255.0 | 172.30.45.1 | 172.30.45.101 
| vlan://untagged | Dhcp | Deallocating | Start   |
|  87 |  59 |204 | 255.255.255.0 | 172.30.45.1 | 172.30.45.101 
| vlan://untagged | Dhcp | Deallocating | Start   |
| 116 |NULL |204 | NULL  | 172.30.45.1 | 172.30.45.101 
| NULL| NULL | Reserved | PlaceHolder |
| 120 |  91 |204 | 255.255.255.0 | 172.30.45.1 | 172.30.45.101 
| vlan://untagged | Dhcp | Reserved | Start   |
|  23 |  14 |204 | 255.255.255.0 | 172.30.45.1 | 172.30.45.102 
| vlan://untagged | Dhcp | Reserved | Start   |
|  21 |  12 |204 | 255.255.255.0 | 172.30.45.1 | 172.30.45.103 
| vlan://untagged | Dhcp | Deallocating | Start   |
| 109 |  81 |204 | 255.255.255.0 | 172.30.45.1 | 172.30.45.103 
| vlan://untagged | Dhcp | Deallocating | Start   |
|   4 |   2 |204 | 255.255.255.0 | 172.30.45.1 | 172.30.45.104 
| vlan://untagged | Dhcp | Deallocating | Start   |
|  84 |  58 |204 | 255.255.255.0 | 172.30.45.1 | 172.30.45.104 
| vlan://untagged | Dhcp | Deallocating | Start   |
|  89 |  60 |204 | 255.255.255.0 | 172.30.45.1 | 172.30.45.104 
| vlan://untagged | Dhcp | Deallocating | Start   |
| 117 |  90 |204 | 255.255.255.0 | 172.30.45.1 | 172.30.45.104 
| vlan://untagged | Dhcp | Reserved | Start   |
|  19 |  10 |204 | 255.255.255.0 | 172.30.45.1 | 172.30.45.105 
| vlan://untagged | Dhcp | Reserved | Start   |
|  34 |  25 |204 | 255.255.255.0 | 172.30.45.1 | 172.30.45.106 
| vlan://untagged | Dhcp | Deallocating | Start   |
|  38 |  29 |204 | 255.255.255.0 | 172.30.45.1 | 172.30.45.106 
| vlan://untagged | Dhcp | Reserved | Start   |
|   8 |   3 |204 | 255.255.255.0 | 172.30.45.1 | 172.30.45.107 
| vlan://untagged | Dhcp | Deallocating | Start   |
|  95 |  64 |204 | 255.255.255.0 | 172.30.45.1 | 172.30.45.107 
| vlan://untagged | Dhcp | Deallocating | Start   |
|  27 |  18 |204 | 255.255.255.0 | 172.30.45.1 | 172.30.45.108 
| vlan://untagged | Dhcp | Deallocating | Start   |
|  28 |  19 |204 | 255.255.255.0 | 172.30.45.1 | 172.30.45.108 
| vlan://untagged | Dhcp | Deallocating | Start   |
|  37 |  28 |204 | 255.255.255.0 | 172.30.45.1 | 172.30.45.

What IPsec VPN could we use to replace OpenSwan?

[Demetrius Tsitrelis]

It doesn't seem that OpenSwan is very actively maintained if there is an issue 
with the OS X client.  Is there another IPsec VPN we could use instead 
(strongSwan, Libreswan, etc.)?

-Original Message-
From: Harikrishna Patnala [mailto:nore...@reviews.apache.org] On Behalf Of 
Harikrishna Patnala
Sent: Tuesday, September 30, 2014 4:42 AM
To: Kishan Kavala; Jayapal Reddy Uradi
Cc: ASF Subversion and Git Services; Harikrishna Patnala; cloudstack
Subject: Re: Review Request 23837: CLOUDSTACK-7087: Downgrade openswan to 
previous version for VPN services to fix OSX client


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/23837/
---

(Updated Sept. 30, 2014, 11:42 a.m.)


Review request for cloudstack, Jayapal Reddy and Kishan Kavala.


Bugs: CLOUDSTACK-7087
https://issues.apache.org/jira/browse/CLOUDSTACK-7087


Repository: cloudstack-git


Description
---

CLOUDSTACK-7087: Downgrade openswan to previous version for VPN services to fix 
OSX client Downgrading openswan version to 1:2.6.37-3


Diffs
-

  tools/appliance/definitions/systemvm64template/postinstall.sh 8763a9f
  tools/appliance/definitions/systemvmtemplate/postinstall.sh 587d44d 

Diff: https://reviews.apache.org/r/23837/diff/


Testing
---


Thanks,

Harikrishna Patnala