Re: CloudStack LTS EOL date?

[Milamber]

Sound good for me too

On 21/11/2017 11:04, Rene Moser wrote:

Hi all

The current LTS release is 4.9 which is EOL in June 2018 according to
https://cwiki.apache.org/confluence/display/CLOUDSTACK/LTS

AFAIK there are no works planed for a new LTS. The release pace has
slown down (the high pace and leaving users behind fixes was the reason
for the LTS).

I am still pro LTS but in my opinion we should have defined the EOL in
relation of the successor LTS release date: "The EOL of the current LTS
is +6 months after the next LTS release."

Small example:

Current LTS 4.9
Next LTS 4.1x release on 01.04. --> LTS 4.9 is 01.10.

Does this make sense? Other suggestions?

Regards
René
.

Re: egress fw problems in 4.10?

[Jayapal Uradi]

Please review the PR.
https://github.com/apache/cloudstack/pull/2334

-Jayapal

On Nov 21, 2017, at 5:37 PM, Rohit Yadav 
> wrote:

Jayapal - nice, can you send a PR please?


- Rohit


From: Jayapal Uradi 
>
Sent: Tuesday, November 21, 2017 5:33:19 PM
To: dev@cloudstack.apache.org
Subject: Re: egress fw problems in 4.10?

Hi,

When there is 0.0.0.0/0 for dest cidr, while adding iptables do not include ' 
-m set --match-set destCidrIpset-4 dst’ .
For 0.0.0.0/0 no need to add this in  ipset.

This should be fixed in VR code.

Thanks,
Jayapal





rohit.ya...@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue



On Nov 21, 2017, at 5:22 PM, Rohit Yadav 
> wrote:

Jayapal - I tried that, that leaves the ipset empty and egress traffic does not 
work for guest VMs.


This is seen in iptables (filter):

[..snipped..]
-A FW_EGRESS_RULES -m set --match-set destCidrIpset-4 dst -j ACCEPT
-A FW_EGRESS_RULES -j DROP
[..snipped..]


And no members are seen:


root@r-4-VM:/var/cache/cloud/processed# ipset list destCidrIpset-4
Name: destCidrIpset-4
Type: hash:net
Revision: 6
Header: family inet hashsize 1024 maxelem 65536
Size in memory: 352
References: 1
Members:

At this point from a guest VM, egress traffic won't be allowed.


However, with the workaround I mentioned (see the bugzilla discussion for 
reference) egress works:


root@r-4-VM:/var/cache/cloud/processed# ipset list destCidrIpset-4
Name: destCidrIpset-4
Type: hash:net
Revision: 6
Header: family inet hashsize 1024 maxelem 65536
Size in memory: 480
References: 1
Members:
0.0.0.0/1
128.0.0.0/1


- Rohit


From: Jayapal Uradi 
>
Sent: Tuesday, November 21, 2017 5:15:57 PM
To: dev@cloudstack.apache.org
Subject: Re: egress fw problems in 4.10?

When there is 0.0.0.0/0 for dest cidr do not add/skip the ipset match option in 
iptables. This will fix the issue.

-Jayapal



rohit.ya...@shapeblue.com
www.shapeblue.com>
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue



On Nov 21, 2017, at 5:07 PM, Rohit Yadav 
> wrote:

Hi Lucian,


It looks like a legit bug: https://bugzilla.redhat.com/show_bug.cgi?id=1297092


When you add 0.0.0.0/0 as destination cidr, this execute on VR and fails:

# ipset add destCidrIpset-4 1.0.0.0/0
ipset v6.30: The value of the CIDR parameter of the IP address is invalid


The workaround are to use these destination cidrs, split in two egress traffic 
rules:

0.0.0.0/1 and 128.0.0.0/1.


Regards.


From: Nux! >
Sent: Tuesday, November 21, 2017 3:16:00 PM
To: dev
Subject: Re: egress fw problems in 4.10?

Rohit,

I see it accepts 0.0.0.0/0 on the source CIDR, but then transforms that into 
10.1.1.0/24 (or whatever), I'd imagine it could do the same with the 
destination CIDR and just "rename" 0.0.0.0/0 into 0.0.0.0/1.
However this is not a Cloudstack problem as I see it, it's an ipset 
bug/feature, so we should just "deal with it", perhaps update the documentation 
at least.

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro


rohit.ya...@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue



- Original Message -
From: "Rohit Yadav" 
>
To: "dev" >
Sent: Tuesday, 21 November, 2017 09:23:00
Subject: Re: egress fw problems in 4.10?

I hit the same issue with the debian9-systemvmtemplate PR. Earlier, the egress
traffic option used to accept 0.0.0.0/0.


- Rohit


From: Nux! >
Sent: Friday, November 17, 2017 11:09:26 PM
To: dev
Subject: Re: egress fw problems in 4.10?

Thanks Jayapal,

Indeed, I checked and 0.0.0.0/0 is not there. When I tried to add it manually I
got an error:
ipset v6.12.1: The value of the CIDR parameter of the IP address is invalid


Hash:net types will not accept 0 prefix, it's happy to accept 0.0.0.0/1 though,
however I still can't do any egress except for ICMP ping for some reason.

If I omit specifying a a dest CIDR, then I get trully unrestricted egress.

I need to investigate some more when I get time, something's fishy.

--
Sent from the Delta quadrant 

Re: Fail with vpn customer gateway creation through terraform

[Jayapal Uradi]

Hi Lucian,

Try the the following in config, ‘-‘ instead of ‘;’ after the aes256 in the 
config.

New: "sha1-aes256-modp3072”
Old: "sha1-aes256;modp3072”

Thanks,
Jayapal
On Nov 22, 2017, at 5:44 AM, Pierre-Luc Dion 
> wrote:

Hi Nux,

Could it be your cloudstack version ?  modp3072 is recent I think in
CloudStack so if you run a older version maybe it's not there?



On Tue, Nov 21, 2017 at 6:55 PM, Nux! > 
wrote:

Thanks Chiradeep,

Checked but brain says no. What should I have learned from there?

AFAIK this is a terraform fail.

Lucian

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
From: "Chiradeep Vittal" 
To: "dev" 
Sent: Tuesday, 21 November, 2017 19:14:16
Subject: Re: Fail with vpn customer gateway creation through terraform

Check
https://github.com/apache/cloudstack/blob/77864992fe8f80dbabd1240f6373d2
ba3e98713c/utils/src/main/java/com/cloud/utils/net/NetUtils.java#L1221

On Tue, Nov 21, 2017 at 10:11 AM, Nux!  wrote:

Hi,

I'm trying out terraform and had success so far, except for the vpn
customer gateway feature.
For some reason, terraform fails to create it, though I use the same
options as in UI/cloudmonkey where it works just fine.

The snippet for it is:

resource "cloudstack_vpn_customer_gateway" "default" {
 name   = "test-vpc"
 cidr   = "10.0.0.0/24"
 esp_policy = "aes256-sha1"
 gateway= "1.2.3.4"
 ike_policy = "sha1-aes256;modp3072"
 ipsec_psk  = "terraformxyz7"
}

It always complains about the ike_policy:
* cloudstack_vpn_customer_gateway.default: Error creating VPN Customer
Gateway test-vpc: Undefined error: {"errorcode":431,"errortext":"The
customer gateway IKE policy sha1-aes256;modp3072 is invalid!  Verify the
required Diffie Hellman (DH) group is specified."}

I tried all sorts of ways to write the ike_policy, escaped, web
encoded/decoded, nothing worked. What am I missing?
The example terraform docs provide suffers the same fate.

Lucian

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro


DISCLAIMER
==
This e-mail may contain privileged and confidential information which is the 
property of Accelerite, a Persistent Systems business. It is intended only for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient, you are not authorized to read, retain, copy, print, 
distribute or use this message. If you have received this communication in 
error, please notify the sender and delete all copies of this message. 
Accelerite, a Persistent Systems business does not accept any liability for 
virus infected mails.

Re: Fail with vpn customer gateway creation through terraform

[Pierre-Luc Dion]

Hi Nux,

Could it be your cloudstack version ?  modp3072 is recent I think in
CloudStack so if you run a older version maybe it's not there?



On Tue, Nov 21, 2017 at 6:55 PM, Nux!  wrote:

> Thanks Chiradeep,
>
> Checked but brain says no. What should I have learned from there?
>
> AFAIK this is a terraform fail.
>
> Lucian
>
> --
> Sent from the Delta quadrant using Borg technology!
>
> Nux!
> www.nux.ro
>
> - Original Message -
> > From: "Chiradeep Vittal" 
> > To: "dev" 
> > Sent: Tuesday, 21 November, 2017 19:14:16
> > Subject: Re: Fail with vpn customer gateway creation through terraform
>
> > Check
> > https://github.com/apache/cloudstack/blob/77864992fe8f80dbabd1240f6373d2
> ba3e98713c/utils/src/main/java/com/cloud/utils/net/NetUtils.java#L1221
> >
> > On Tue, Nov 21, 2017 at 10:11 AM, Nux!  wrote:
> >
> >> Hi,
> >>
> >> I'm trying out terraform and had success so far, except for the vpn
> >> customer gateway feature.
> >> For some reason, terraform fails to create it, though I use the same
> >> options as in UI/cloudmonkey where it works just fine.
> >>
> >> The snippet for it is:
> >>
> >> resource "cloudstack_vpn_customer_gateway" "default" {
> >>   name   = "test-vpc"
> >>   cidr   = "10.0.0.0/24"
> >>   esp_policy = "aes256-sha1"
> >>   gateway= "1.2.3.4"
> >>   ike_policy = "sha1-aes256;modp3072"
> >>   ipsec_psk  = "terraformxyz7"
> >> }
> >>
> >> It always complains about the ike_policy:
> >> * cloudstack_vpn_customer_gateway.default: Error creating VPN Customer
> >> Gateway test-vpc: Undefined error: {"errorcode":431,"errortext":"The
> >> customer gateway IKE policy sha1-aes256;modp3072 is invalid!  Verify the
> >> required Diffie Hellman (DH) group is specified."}
> >>
> >> I tried all sorts of ways to write the ike_policy, escaped, web
> >> encoded/decoded, nothing worked. What am I missing?
> >> The example terraform docs provide suffers the same fate.
> >>
> >> Lucian
> >>
> >> --
> >> Sent from the Delta quadrant using Borg technology!
> >>
> >> Nux!
> >> www.nux.ro
>

Re: Fail with vpn customer gateway creation through terraform

[Nux!]

Thanks Chiradeep,

Checked but brain says no. What should I have learned from there?

AFAIK this is a terraform fail.

Lucian

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
> From: "Chiradeep Vittal" 
> To: "dev" 
> Sent: Tuesday, 21 November, 2017 19:14:16
> Subject: Re: Fail with vpn customer gateway creation through terraform

> Check
> https://github.com/apache/cloudstack/blob/77864992fe8f80dbabd1240f6373d2ba3e98713c/utils/src/main/java/com/cloud/utils/net/NetUtils.java#L1221
> 
> On Tue, Nov 21, 2017 at 10:11 AM, Nux!  wrote:
> 
>> Hi,
>>
>> I'm trying out terraform and had success so far, except for the vpn
>> customer gateway feature.
>> For some reason, terraform fails to create it, though I use the same
>> options as in UI/cloudmonkey where it works just fine.
>>
>> The snippet for it is:
>>
>> resource "cloudstack_vpn_customer_gateway" "default" {
>>   name   = "test-vpc"
>>   cidr   = "10.0.0.0/24"
>>   esp_policy = "aes256-sha1"
>>   gateway= "1.2.3.4"
>>   ike_policy = "sha1-aes256;modp3072"
>>   ipsec_psk  = "terraformxyz7"
>> }
>>
>> It always complains about the ike_policy:
>> * cloudstack_vpn_customer_gateway.default: Error creating VPN Customer
>> Gateway test-vpc: Undefined error: {"errorcode":431,"errortext":"The
>> customer gateway IKE policy sha1-aes256;modp3072 is invalid!  Verify the
>> required Diffie Hellman (DH) group is specified."}
>>
>> I tried all sorts of ways to write the ike_policy, escaped, web
>> encoded/decoded, nothing worked. What am I missing?
>> The example terraform docs provide suffers the same fate.
>>
>> Lucian
>>
>> --
>> Sent from the Delta quadrant using Borg technology!
>>
>> Nux!
>> www.nux.ro

Re: Fail with vpn customer gateway creation through terraform

[Chiradeep Vittal]

Check
https://github.com/apache/cloudstack/blob/77864992fe8f80dbabd1240f6373d2ba3e98713c/utils/src/main/java/com/cloud/utils/net/NetUtils.java#L1221

On Tue, Nov 21, 2017 at 10:11 AM, Nux!  wrote:

> Hi,
>
> I'm trying out terraform and had success so far, except for the vpn
> customer gateway feature.
> For some reason, terraform fails to create it, though I use the same
> options as in UI/cloudmonkey where it works just fine.
>
> The snippet for it is:
>
> resource "cloudstack_vpn_customer_gateway" "default" {
>   name   = "test-vpc"
>   cidr   = "10.0.0.0/24"
>   esp_policy = "aes256-sha1"
>   gateway= "1.2.3.4"
>   ike_policy = "sha1-aes256;modp3072"
>   ipsec_psk  = "terraformxyz7"
> }
>
> It always complains about the ike_policy:
> * cloudstack_vpn_customer_gateway.default: Error creating VPN Customer
> Gateway test-vpc: Undefined error: {"errorcode":431,"errortext":"The
> customer gateway IKE policy sha1-aes256;modp3072 is invalid!  Verify the
> required Diffie Hellman (DH) group is specified."}
>
> I tried all sorts of ways to write the ike_policy, escaped, web
> encoded/decoded, nothing worked. What am I missing?
> The example terraform docs provide suffers the same fate.
>
> Lucian
>
> --
> Sent from the Delta quadrant using Borg technology!
>
> Nux!
> www.nux.ro
>

Fail with vpn customer gateway creation through terraform

[Nux!]

Hi,

I'm trying out terraform and had success so far, except for the vpn customer 
gateway feature.
For some reason, terraform fails to create it, though I use the same options as 
in UI/cloudmonkey where it works just fine.

The snippet for it is:

resource "cloudstack_vpn_customer_gateway" "default" {
  name   = "test-vpc"
  cidr   = "10.0.0.0/24"
  esp_policy = "aes256-sha1"
  gateway= "1.2.3.4"
  ike_policy = "sha1-aes256;modp3072"
  ipsec_psk  = "terraformxyz7"
}

It always complains about the ike_policy:
* cloudstack_vpn_customer_gateway.default: Error creating VPN Customer Gateway 
test-vpc: Undefined error: {"errorcode":431,"errortext":"The customer gateway 
IKE policy sha1-aes256;modp3072 is invalid!  Verify the required Diffie Hellman 
(DH) group is specified."}

I tried all sorts of ways to write the ike_policy, escaped, web 
encoded/decoded, nothing worked. What am I missing?
The example terraform docs provide suffers the same fate.

Lucian

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

Re: [DISCUSS] Move to Debian9 systemvmtemplate

[Rene Moser]

Hi Rohit

First, thank you very much for the effort!

On 11/21/2017 01:07 PM, Rohit Yadav wrote:

> Please advise if you can collaborate with me on this, especially around 
> testing. Thanks!

I have some 2 "nice to have"s, AFAICS these haven't been addressed yet:

- SNMP readonly listen on "linklocalip"
- HAProxy stats (or even exporter
https://github.com/prometheus/haproxy_exporter) listen on linklocalip

Regards
René

Re: CloudStack LTS EOL date?

[Ivan Kudryavtsev]

Hello, it sounds very reasonable. The more lifecycle information the better
for adopters.

21 нояб. 2017 г. 8:56 ПП пользователь "Marc-Aurèle Brothier - Exoscale" <
ma...@exoscale.ch> написал:

> It makes more sense to me too.
>
>
> On Tue, 2017-11-21 at 12:04 +0100, Rene Moser wrote:
> > Hi all
> >
> > The current LTS release is 4.9 which is EOL in June 2018 according to
> > https://cwiki.apache.org/confluence/display/CLOUDSTACK/LTS
> >
> > AFAIK there are no works planed for a new LTS. The release pace has
> > slown down (the high pace and leaving users behind fixes was the
> > reason
> > for the LTS).
> >
> > I am still pro LTS but in my opinion we should have defined the EOL
> > in
> > relation of the successor LTS release date: "The EOL of the current
> > LTS
> > is +6 months after the next LTS release."
> >
> > Small example:
> >
> > Current LTS 4.9
> > Next LTS 4.1x release on 01.04. --> LTS 4.9 is 01.10.
> >
> > Does this make sense? Other suggestions?
> >
> > Regards
> > René
>

Re: CloudStack LTS EOL date?

[Marc-Aurèle Brothier - Exoscale]

It makes more sense to me too.


On Tue, 2017-11-21 at 12:04 +0100, Rene Moser wrote:
> Hi all
> 
> The current LTS release is 4.9 which is EOL in June 2018 according to
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/LTS
> 
> AFAIK there are no works planed for a new LTS. The release pace has
> slown down (the high pace and leaving users behind fixes was the
> reason
> for the LTS).
> 
> I am still pro LTS but in my opinion we should have defined the EOL
> in
> relation of the successor LTS release date: "The EOL of the current
> LTS
> is +6 months after the next LTS release."
> 
> Small example:
> 
> Current LTS 4.9
> Next LTS 4.1x release on 01.04. --> LTS 4.9 is 01.10.
> 
> Does this make sense? Other suggestions?
> 
> Regards
> René

Re: egress fw problems in 4.10?

[Rohit Yadav]

Jayapal - nice, can you send a PR please?


- Rohit


From: Jayapal Uradi 
Sent: Tuesday, November 21, 2017 5:33:19 PM
To: dev@cloudstack.apache.org
Subject: Re: egress fw problems in 4.10?

Hi,

When there is 0.0.0.0/0 for dest cidr, while adding iptables do not include ' 
-m set --match-set destCidrIpset-4 dst’ .
For 0.0.0.0/0 no need to add this in  ipset.

This should be fixed in VR code.

Thanks,
Jayapal





rohit.ya...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
  
 

> On Nov 21, 2017, at 5:22 PM, Rohit Yadav  wrote:
>
> Jayapal - I tried that, that leaves the ipset empty and egress traffic does 
> not work for guest VMs.
>
>
> This is seen in iptables (filter):
>
> [..snipped..]
> -A FW_EGRESS_RULES -m set --match-set destCidrIpset-4 dst -j ACCEPT
> -A FW_EGRESS_RULES -j DROP
> [..snipped..]
>
>
> And no members are seen:
>
>
> root@r-4-VM:/var/cache/cloud/processed# ipset list destCidrIpset-4
> Name: destCidrIpset-4
> Type: hash:net
> Revision: 6
> Header: family inet hashsize 1024 maxelem 65536
> Size in memory: 352
> References: 1
> Members:
>
> At this point from a guest VM, egress traffic won't be allowed.
>
>
> However, with the workaround I mentioned (see the bugzilla discussion for 
> reference) egress works:
>
>
> root@r-4-VM:/var/cache/cloud/processed# ipset list destCidrIpset-4
> Name: destCidrIpset-4
> Type: hash:net
> Revision: 6
> Header: family inet hashsize 1024 maxelem 65536
> Size in memory: 480
> References: 1
> Members:
> 0.0.0.0/1
> 128.0.0.0/1
>
>
> - Rohit
>
> 
> From: Jayapal Uradi 
> Sent: Tuesday, November 21, 2017 5:15:57 PM
> To: dev@cloudstack.apache.org
> Subject: Re: egress fw problems in 4.10?
>
> When there is 0.0.0.0/0 for dest cidr do not add/skip the ipset match option 
> in iptables. This will fix the issue.
>
> -Jayapal
>
>
>
> rohit.ya...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
>
>
>
> On Nov 21, 2017, at 5:07 PM, Rohit Yadav 
> > wrote:
>
> Hi Lucian,
>
>
> It looks like a legit bug: https://bugzilla.redhat.com/show_bug.cgi?id=1297092
>
>
> When you add 0.0.0.0/0 as destination cidr, this execute on VR and fails:
>
> # ipset add destCidrIpset-4 1.0.0.0/0
> ipset v6.30: The value of the CIDR parameter of the IP address is invalid
>
>
> The workaround are to use these destination cidrs, split in two egress 
> traffic rules:
>
> 0.0.0.0/1 and 128.0.0.0/1.
>
>
> Regards.
>
> 
> From: Nux! >
> Sent: Tuesday, November 21, 2017 3:16:00 PM
> To: dev
> Subject: Re: egress fw problems in 4.10?
>
> Rohit,
>
> I see it accepts 0.0.0.0/0 on the source CIDR, but then transforms that into 
> 10.1.1.0/24 (or whatever), I'd imagine it could do the same with the 
> destination CIDR and just "rename" 0.0.0.0/0 into 0.0.0.0/1.
> However this is not a Cloudstack problem as I see it, it's an ipset 
> bug/feature, so we should just "deal with it", perhaps update the 
> documentation at least.
>
> --
> Sent from the Delta quadrant using Borg technology!
>
> Nux!
> www.nux.ro
>
>
> rohit.ya...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
>
>
>
> - Original Message -
> From: "Rohit Yadav" 
> >
> To: "dev" >
> Sent: Tuesday, 21 November, 2017 09:23:00
> Subject: Re: egress fw problems in 4.10?
>
> I hit the same issue with the debian9-systemvmtemplate PR. Earlier, the egress
> traffic option used to accept 0.0.0.0/0.
>
>
> - Rohit
>
> 
> From: Nux! >
> Sent: Friday, November 17, 2017 11:09:26 PM
> To: dev
> Subject: Re: egress fw problems in 4.10?
>
> Thanks Jayapal,
>
> Indeed, I checked and 0.0.0.0/0 is not there. When I tried to add it manually 
> I
> got an error:
> ipset v6.12.1: The value of the CIDR parameter of the IP address is invalid
>
>
> Hash:net types will not accept 0 prefix, it's happy to accept 0.0.0.0/1 
> though,
> however I still can't do any egress except for ICMP ping for some reason.
>
> If I omit specifying a a dest CIDR, then I get trully unrestricted egress.
>
> I need to investigate some more when I get time, something's fishy.
>
> --
> Sent from the Delta quadrant using Borg technology!
>
> Nux!
> www.nux.ro
>
>
> rohit.ya...@shapeblue.com
> www.shapeblue.com>
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> 

Re: [DISCUSS] Move to Debian9 systemvmtemplate

[Rohit Yadav]

All,


I wanted to revive this thread and bring recent progress to your attention:


- We're now able to build debian9 based systemvmtemplates successfully that 
work okay-ish as CPVM/SSVM host and some initial networking support (dns, dhcp, 
basic zone, advanced zone: firewall, pf, snat etc.) for VirtualRouter

- Several optimization improvements around disk size, services load time, a lot 
of work still to be done

- Several services migrated to use systemd, pending optimizations

- PR: https://github.com/apache/cloudstack/pull/2211


I could finally deploy a test KVM environment (advanced zone) and run some 
smoke tests on it, they are available in the above-mentioned PR. Most failures 
are around networking and services.


Given Debian7 has EOL-ed, and Java7 too, I think it's about time to work on 
this and aim to get this done for ACS 4.11 (end of Q1/2018). Please share your 
feedback and comments.


Using Trillian we can test the "migration to a debian9/java8 based template" PR 
against KVM, XenServer and VMware, however, what other hypervisors should we be 
testing/supporting - HyperV, baremetal, OVM etc? What are the status of these 
hypervisor plugins - baremetal, hyperv, lxc, ovm/ovm3, ucs?


Please advise if you can collaborate with me on this, especially around 
testing. Thanks!


Regards.



From: Rohit Yadav 
Sent: Monday, July 31, 2017 3:05:30 PM
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] Move to Debian9 systemvmtemplate

Moving to a packer based build system can still reuse the same scripts and 
recipes to build a systemvmtemplate which is agnostic of who/how you build it. 
With lack of time and resources, moving to debian9 based systemvmtemplate is a 
much needed effort and moving to a new build system can be a next step.

The current build system may not be perfect, may be tricky to setup at first. 
Most recently updated docs are at tools/appliance/README.md, if anyone has 
issues you may ping me and I may be able to help.

Now back to the topic of supporting debian9 as systemvmtemplate base, I was 
able to get something up and running this weekend and get serial console. I 
could also verify some patching done by the systemvm.iso file however I'm 
facing issues with running cloud-early-config, postinit and cloud services in a 
certain order and I need help around the systemd scripts.

Here's the PR:
https://github.com/apache/cloudstack/pull/2211

The PR branch is pushed on ASF remote so any committer can collaborate with me 
by pushing changes/fixes as a separate commit on that branch, feel free to do 
so. Thanks.

- Rohit

From: Paul Angus 
Sent: Monday, July 31, 2017 11:11:53 AM
To: dev@cloudstack.apache.org
Subject: RE: [DISCUSS] Move to Debian9 systemvmtemplate

Depending on the timescales that we looking at, if we can get an agreement to 
use Packer going forward, there is an argument to say that spending time 
getting the Debian 9 template to work on VeeWee and then on Packer is wasted 
effort and that we should just use this as the opportunity to move over to 
Packer/Debian9.

Having spent the weekend fighting with RVM/VeeWee/Ruby.  And finding that we've 
hard linked rvm to Ruby 2.1.1 when it's now on 2.4, Veewee hasn't been updated 
for years  and other mismatches.  I'm very interested to see other options 
explored.

Veewee doesn't do the disk conversions at them moment, so we can still keep 
that a separate process for corner cases that Packer (or something else) can't 
manage..

Kind regards,

Paul Angus

paul.an...@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue




rohit.ya...@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue




rohit.ya...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
  
 


-Original Message-
From: Rohit Yadav [mailto:rohit.ya...@shapeblue.com]
Sent: 28 July 2017 20:30
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] Move to Debian9 systemvmtemplate

I think we can move to packer once we can get the Debian9 based 
systemvmtemplate to work.

I think we should focus on doing this first and then focus on migration to a 
new build system as a next step.


I spent some time today and with some help from veewee authors, I could get a 
base template up and running:

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


The above PR branch is pushed on ASF remote and allows for cross-collaboration 
with all ACS committers. Please collaborate with me on this and feel free to 
push changes on the branch as separate commits and/or make changes to the PR. 
Thanks.


- Rohit


From: Tim Mackey 
Sent: Friday, July 28, 2017 3:59:36 AM
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] Move to 

Re: egress fw problems in 4.10?

[Jayapal Uradi]

Hi,

When there is 0.0.0.0/0 for dest cidr, while adding iptables do not include ' 
-m set --match-set destCidrIpset-4 dst’ .
For 0.0.0.0/0 no need to add this in  ipset.

This should be fixed in VR code.

Thanks,
Jayapal




> On Nov 21, 2017, at 5:22 PM, Rohit Yadav  wrote:
> 
> Jayapal - I tried that, that leaves the ipset empty and egress traffic does 
> not work for guest VMs.
> 
> 
> This is seen in iptables (filter):
> 
> [..snipped..]
> -A FW_EGRESS_RULES -m set --match-set destCidrIpset-4 dst -j ACCEPT
> -A FW_EGRESS_RULES -j DROP
> [..snipped..]
> 
> 
> And no members are seen:
> 
> 
> root@r-4-VM:/var/cache/cloud/processed# ipset list destCidrIpset-4
> Name: destCidrIpset-4
> Type: hash:net
> Revision: 6
> Header: family inet hashsize 1024 maxelem 65536
> Size in memory: 352
> References: 1
> Members:
> 
> At this point from a guest VM, egress traffic won't be allowed.
> 
> 
> However, with the workaround I mentioned (see the bugzilla discussion for 
> reference) egress works:
> 
> 
> root@r-4-VM:/var/cache/cloud/processed# ipset list destCidrIpset-4
> Name: destCidrIpset-4
> Type: hash:net
> Revision: 6
> Header: family inet hashsize 1024 maxelem 65536
> Size in memory: 480
> References: 1
> Members:
> 0.0.0.0/1
> 128.0.0.0/1
> 
> 
> - Rohit
> 
> 
> From: Jayapal Uradi 
> Sent: Tuesday, November 21, 2017 5:15:57 PM
> To: dev@cloudstack.apache.org
> Subject: Re: egress fw problems in 4.10?
> 
> When there is 0.0.0.0/0 for dest cidr do not add/skip the ipset match option 
> in iptables. This will fix the issue.
> 
> -Jayapal
> 
> 
> 
> rohit.ya...@shapeblue.com 
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
> 
> 
> 
> On Nov 21, 2017, at 5:07 PM, Rohit Yadav 
> > wrote:
> 
> Hi Lucian,
> 
> 
> It looks like a legit bug: https://bugzilla.redhat.com/show_bug.cgi?id=1297092
> 
> 
> When you add 0.0.0.0/0 as destination cidr, this execute on VR and fails:
> 
> # ipset add destCidrIpset-4 1.0.0.0/0
> ipset v6.30: The value of the CIDR parameter of the IP address is invalid
> 
> 
> The workaround are to use these destination cidrs, split in two egress 
> traffic rules:
> 
> 0.0.0.0/1 and 128.0.0.0/1.
> 
> 
> Regards.
> 
> 
> From: Nux! >
> Sent: Tuesday, November 21, 2017 3:16:00 PM
> To: dev
> Subject: Re: egress fw problems in 4.10?
> 
> Rohit,
> 
> I see it accepts 0.0.0.0/0 on the source CIDR, but then transforms that into 
> 10.1.1.0/24 (or whatever), I'd imagine it could do the same with the 
> destination CIDR and just "rename" 0.0.0.0/0 into 0.0.0.0/1.
> However this is not a Cloudstack problem as I see it, it's an ipset 
> bug/feature, so we should just "deal with it", perhaps update the 
> documentation at least.
> 
> --
> Sent from the Delta quadrant using Borg technology!
> 
> Nux!
> www.nux.ro
> 
> 
> rohit.ya...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
> 
> 
> 
> - Original Message -
> From: "Rohit Yadav" 
> >
> To: "dev" >
> Sent: Tuesday, 21 November, 2017 09:23:00
> Subject: Re: egress fw problems in 4.10?
> 
> I hit the same issue with the debian9-systemvmtemplate PR. Earlier, the egress
> traffic option used to accept 0.0.0.0/0.
> 
> 
> - Rohit
> 
> 
> From: Nux! >
> Sent: Friday, November 17, 2017 11:09:26 PM
> To: dev
> Subject: Re: egress fw problems in 4.10?
> 
> Thanks Jayapal,
> 
> Indeed, I checked and 0.0.0.0/0 is not there. When I tried to add it manually 
> I
> got an error:
> ipset v6.12.1: The value of the CIDR parameter of the IP address is invalid
> 
> 
> Hash:net types will not accept 0 prefix, it's happy to accept 0.0.0.0/1 
> though,
> however I still can't do any egress except for ICMP ping for some reason.
> 
> If I omit specifying a a dest CIDR, then I get trully unrestricted egress.
> 
> I need to investigate some more when I get time, something's fishy.
> 
> --
> Sent from the Delta quadrant using Borg technology!
> 
> Nux!
> www.nux.ro
> 
> 
> rohit.ya...@shapeblue.com
> www.shapeblue.com>
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
> 
> 
> 
> - Original Message -
> From: "Jayapal Uradi" 
> To: "dev" 
> Sent: Friday, 17 November, 2017 04:02:13
> Subject: Re: egress fw problems in 4.10?
> 
> Hi Nux,
> 
> I think the the ipset for destination cidr is not configured with 0.0.0.0/0 
> due
> this 

Re: egress fw problems in 4.10?

[Rohit Yadav]

Jayapal - I tried that, that leaves the ipset empty and egress traffic does not 
work for guest VMs.


This is seen in iptables (filter):

[..snipped..]
-A FW_EGRESS_RULES -m set --match-set destCidrIpset-4 dst -j ACCEPT
-A FW_EGRESS_RULES -j DROP
[..snipped..]


And no members are seen:


root@r-4-VM:/var/cache/cloud/processed# ipset list destCidrIpset-4
Name: destCidrIpset-4
Type: hash:net
Revision: 6
Header: family inet hashsize 1024 maxelem 65536
Size in memory: 352
References: 1
Members:

At this point from a guest VM, egress traffic won't be allowed.


However, with the workaround I mentioned (see the bugzilla discussion for 
reference) egress works:


root@r-4-VM:/var/cache/cloud/processed# ipset list destCidrIpset-4
Name: destCidrIpset-4
Type: hash:net
Revision: 6
Header: family inet hashsize 1024 maxelem 65536
Size in memory: 480
References: 1
Members:
0.0.0.0/1
128.0.0.0/1


- Rohit


From: Jayapal Uradi 
Sent: Tuesday, November 21, 2017 5:15:57 PM
To: dev@cloudstack.apache.org
Subject: Re: egress fw problems in 4.10?

When there is 0.0.0.0/0 for dest cidr do not add/skip the ipset match option in 
iptables. This will fix the issue.

-Jayapal



rohit.ya...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
  
 

On Nov 21, 2017, at 5:07 PM, Rohit Yadav 
> wrote:

Hi Lucian,


It looks like a legit bug: https://bugzilla.redhat.com/show_bug.cgi?id=1297092


When you add 0.0.0.0/0 as destination cidr, this execute on VR and fails:

# ipset add destCidrIpset-4 1.0.0.0/0
ipset v6.30: The value of the CIDR parameter of the IP address is invalid


The workaround are to use these destination cidrs, split in two egress traffic 
rules:

0.0.0.0/1 and 128.0.0.0/1.


Regards.


From: Nux! >
Sent: Tuesday, November 21, 2017 3:16:00 PM
To: dev
Subject: Re: egress fw problems in 4.10?

Rohit,

I see it accepts 0.0.0.0/0 on the source CIDR, but then transforms that into 
10.1.1.0/24 (or whatever), I'd imagine it could do the same with the 
destination CIDR and just "rename" 0.0.0.0/0 into 0.0.0.0/1.
However this is not a Cloudstack problem as I see it, it's an ipset 
bug/feature, so we should just "deal with it", perhaps update the documentation 
at least.

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro


rohit.ya...@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue



- Original Message -
From: "Rohit Yadav" 
>
To: "dev" >
Sent: Tuesday, 21 November, 2017 09:23:00
Subject: Re: egress fw problems in 4.10?

I hit the same issue with the debian9-systemvmtemplate PR. Earlier, the egress
traffic option used to accept 0.0.0.0/0.


- Rohit


From: Nux! >
Sent: Friday, November 17, 2017 11:09:26 PM
To: dev
Subject: Re: egress fw problems in 4.10?

Thanks Jayapal,

Indeed, I checked and 0.0.0.0/0 is not there. When I tried to add it manually I
got an error:
ipset v6.12.1: The value of the CIDR parameter of the IP address is invalid


Hash:net types will not accept 0 prefix, it's happy to accept 0.0.0.0/1 though,
however I still can't do any egress except for ICMP ping for some reason.

If I omit specifying a a dest CIDR, then I get trully unrestricted egress.

I need to investigate some more when I get time, something's fishy.

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro


rohit.ya...@shapeblue.com
www.shapeblue.com>
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue



- Original Message -
From: "Jayapal Uradi" 
To: "dev" 
Sent: Friday, 17 November, 2017 04:02:13
Subject: Re: egress fw problems in 4.10?

Hi Nux,

I think the the ipset for destination cidr is not configured with 0.0.0.0/0 due
this you might see this issue.
Please check the ipset and iptables rules once.

iptables -L -nv
ipset -L

Thanks,
Jayapal


On Nov 17, 2017, a t 6:55 AM, Nux!  wrote:

Hi,

Just installed 4.10 today for a demo, but seems there are some problems with the
egress rules in isolated networks.
Is there anything wrong with this rule? ACS allows me to add it, but no outbound
traffic is allowed at all.

10.1.1.0/24  0.0.0.0/0   All All All

http://img.nux.ro/gL3-Selection_002.png

If I replace 0.0.0.0/0 with a certain IP/32, then traffic works.


Also, if I don't mention a destination cidr at all, outbound traffic also works,
but the docs 

Re: egress fw problems in 4.10?

[Jayapal Uradi]

When there is 0.0.0.0/0 for dest cidr do not add/skip the ipset match option in 
iptables. This will fix the issue.

-Jayapal


On Nov 21, 2017, at 5:07 PM, Rohit Yadav 
> wrote:

Hi Lucian,


It looks like a legit bug: https://bugzilla.redhat.com/show_bug.cgi?id=1297092


When you add 0.0.0.0/0 as destination cidr, this execute on VR and fails:

# ipset add destCidrIpset-4 1.0.0.0/0
ipset v6.30: The value of the CIDR parameter of the IP address is invalid


The workaround are to use these destination cidrs, split in two egress traffic 
rules:

0.0.0.0/1 and 128.0.0.0/1.


Regards.


From: Nux! >
Sent: Tuesday, November 21, 2017 3:16:00 PM
To: dev
Subject: Re: egress fw problems in 4.10?

Rohit,

I see it accepts 0.0.0.0/0 on the source CIDR, but then transforms that into 
10.1.1.0/24 (or whatever), I'd imagine it could do the same with the 
destination CIDR and just "rename" 0.0.0.0/0 into 0.0.0.0/1.
However this is not a Cloudstack problem as I see it, it's an ipset 
bug/feature, so we should just "deal with it", perhaps update the documentation 
at least.

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro


rohit.ya...@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue



- Original Message -
From: "Rohit Yadav" 
>
To: "dev" >
Sent: Tuesday, 21 November, 2017 09:23:00
Subject: Re: egress fw problems in 4.10?

I hit the same issue with the debian9-systemvmtemplate PR. Earlier, the egress
traffic option used to accept 0.0.0.0/0.


- Rohit


From: Nux! >
Sent: Friday, November 17, 2017 11:09:26 PM
To: dev
Subject: Re: egress fw problems in 4.10?

Thanks Jayapal,

Indeed, I checked and 0.0.0.0/0 is not there. When I tried to add it manually I
got an error:
ipset v6.12.1: The value of the CIDR parameter of the IP address is invalid


Hash:net types will not accept 0 prefix, it's happy to accept 0.0.0.0/1 though,
however I still can't do any egress except for ICMP ping for some reason.

If I omit specifying a a dest CIDR, then I get trully unrestricted egress.

I need to investigate some more when I get time, something's fishy.

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro


rohit.ya...@shapeblue.com
www.shapeblue.com>
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue



- Original Message -
From: "Jayapal Uradi" 
To: "dev" 
Sent: Friday, 17 November, 2017 04:02:13
Subject: Re: egress fw problems in 4.10?

Hi Nux,

I think the the ipset for destination cidr is not configured with 0.0.0.0/0 due
this you might see this issue.
Please check the ipset and iptables rules once.

iptables -L -nv
ipset -L

Thanks,
Jayapal


On Nov 17, 2017, a t 6:55 AM, Nux!  wrote:

Hi,

Just installed 4.10 today for a demo, but seems there are some problems with the
egress rules in isolated networks.
Is there anything wrong with this rule? ACS allows me to add it, but no outbound
traffic is allowed at all.

10.1.1.0/24  0.0.0.0/0   All All All

http://img.nux.ro/gL3-Selection_002.png

If I replace 0.0.0.0/0 with a certain IP/32, then traffic works.


Also, if I don't mention a destination cidr at all, outbound traffic also works,
but the docs state 0.0.0.0/0 should be honoured as valid destination cidr.

Any ideas? I know there was recent work done on egress recently, maybe related
to that?

Lucian

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

DISCLAIMER
==
This e-mail may contain privileged and confidential information which is the
property of Accelerite, a Persistent Systems business. It is intended only for
the use of the individual or entity to which it is addressed. If you are not
the intended recipient, you are not authorized to read, retain, copy, print,
distribute or use this message. If you have received this communication in
error, please notify the sender and delete all copies of this message.
Accelerite, a Persistent Systems business does not accept any liability for
virus infected mails.

DISCLAIMER
==
This e-mail may contain privileged and confidential information which is the 
property of Accelerite, a Persistent Systems business. It is intended only for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient, you are not authorized to read, retain, copy, print, 
distribute or use this message. If you have received this communication in 

Re: egress fw problems in 4.10?

[Rohit Yadav]

Hi Lucian,


It looks like a legit bug: https://bugzilla.redhat.com/show_bug.cgi?id=1297092


When you add 0.0.0.0/0 as destination cidr, this execute on VR and fails:

# ipset add destCidrIpset-4 1.0.0.0/0
ipset v6.30: The value of the CIDR parameter of the IP address is invalid


The workaround are to use these destination cidrs, split in two egress traffic 
rules:

0.0.0.0/1 and 128.0.0.0/1.


Regards.


From: Nux! 
Sent: Tuesday, November 21, 2017 3:16:00 PM
To: dev
Subject: Re: egress fw problems in 4.10?

Rohit,

I see it accepts 0.0.0.0/0 on the source CIDR, but then transforms that into 
10.1.1.0/24 (or whatever), I'd imagine it could do the same with the 
destination CIDR and just "rename" 0.0.0.0/0 into 0.0.0.0/1.
However this is not a Cloudstack problem as I see it, it's an ipset 
bug/feature, so we should just "deal with it", perhaps update the documentation 
at least.

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro


rohit.ya...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
  
 

- Original Message -
> From: "Rohit Yadav" 
> To: "dev" 
> Sent: Tuesday, 21 November, 2017 09:23:00
> Subject: Re: egress fw problems in 4.10?

> I hit the same issue with the debian9-systemvmtemplate PR. Earlier, the egress
> traffic option used to accept 0.0.0.0/0.
>
>
> - Rohit
>
> 
> From: Nux! 
> Sent: Friday, November 17, 2017 11:09:26 PM
> To: dev
> Subject: Re: egress fw problems in 4.10?
>
> Thanks Jayapal,
>
> Indeed, I checked and 0.0.0.0/0 is not there. When I tried to add it manually 
> I
> got an error:
> ipset v6.12.1: The value of the CIDR parameter of the IP address is invalid
>
>
> Hash:net types will not accept 0 prefix, it's happy to accept 0.0.0.0/1 
> though,
> however I still can't do any egress except for ICMP ping for some reason.
>
> If I omit specifying a a dest CIDR, then I get trully unrestricted egress.
>
> I need to investigate some more when I get time, something's fishy.
>
> --
> Sent from the Delta quadrant using Borg technology!
>
> Nux!
> www.nux.ro
>
>
> rohit.ya...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
>
>
>
> - Original Message -
>> From: "Jayapal Uradi" 
>> To: "dev" 
>> Sent: Friday, 17 November, 2017 04:02:13
>> Subject: Re: egress fw problems in 4.10?
>
>> Hi Nux,
>>
>> I think the the ipset for destination cidr is not configured with 0.0.0.0/0 
>> due
>> this you might see this issue.
>> Please check the ipset and iptables rules once.
>>
>> iptables -L -nv
>> ipset -L
>>
>> Thanks,
>> Jayapal
>>
>>
>>> On Nov 17, 2017, a t 6:55 AM, Nux!  wrote:
>>>
>>> Hi,
>>>
>>> Just installed 4.10 today for a demo, but seems there are some problems 
>>> with the
>>> egress rules in isolated networks.
>>> Is there anything wrong with this rule? ACS allows me to add it, but no 
>>> outbound
>>> traffic is allowed at all.
>>>
>>> 10.1.1.0/24  0.0.0.0/0   All All All
>>>
>>> http://img.nux.ro/gL3-Selection_002.png
>>>
>>> If I replace 0.0.0.0/0 with a certain IP/32, then traffic works.
>>>
>>>
>>> Also, if I don't mention a destination cidr at all, outbound traffic also 
>>> works,
>>> but the docs state 0.0.0.0/0 should be honoured as valid destination cidr.
>>>
>>> Any ideas? I know there was recent work done on egress recently, maybe 
>>> related
>>> to that?
>>>
>>> Lucian
>>>
>>> --
>>> Sent from the Delta quadrant using Borg technology!
>>>
>>> Nux!
>>> www.nux.ro
>>
>> DISCLAIMER
>> ==
>> This e-mail may contain privileged and confidential information which is the
>> property of Accelerite, a Persistent Systems business. It is intended only 
>> for
>> the use of the individual or entity to which it is addressed. If you are not
>> the intended recipient, you are not authorized to read, retain, copy, print,
>> distribute or use this message. If you have received this communication in
>> error, please notify the sender and delete all copies of this message.
>> Accelerite, a Persistent Systems business does not accept any liability for
> > virus infected mails.

CloudStack LTS EOL date?

[Rene Moser]

Hi all

The current LTS release is 4.9 which is EOL in June 2018 according to
https://cwiki.apache.org/confluence/display/CLOUDSTACK/LTS

AFAIK there are no works planed for a new LTS. The release pace has
slown down (the high pace and leaving users behind fixes was the reason
for the LTS).

I am still pro LTS but in my opinion we should have defined the EOL in
relation of the successor LTS release date: "The EOL of the current LTS
is +6 months after the next LTS release."

Small example:

Current LTS 4.9
Next LTS 4.1x release on 01.04. --> LTS 4.9 is 01.10.

Does this make sense? Other suggestions?

Regards
René

Re: No database selected for the transaction

[Alireza Eskandari]

I should say that I'm using a cluster of MariaDB on Galera with 3
nodes. All of them are master but I'm using one node at a time by
assign a virtual IP to it.
Here is db.properties on node1:

# management server clustering parameters, change cluster.node.IP to
the machine IP address
# in which the management server(Tomcat) is running
cluster.node.IP=172.17.60.31
cluster.servlet.port=9090
region.id=1

# CloudStack database settings
db.cloud.username=cloud
db.cloud.password=ENC()
db.cloud.host=csdb-cltr01.cloud.local
db.cloud.driver=jdbc:mysql
db.cloud.port=3306
db.cloud.name=cloud

# CloudStack database tuning parameters
db.cloud.maxActive=250
db.cloud.maxIdle=30
db.cloud.maxWait=1
db.cloud.validationQuery=SELECT 1
db.cloud.testOnBorrow=true
db.cloud.testWhileIdle=true
db.cloud.timeBetweenEvictionRunsMillis=4
db.cloud.minEvictableIdleTimeMillis=24
db.cloud.poolPreparedStatements=false
db.cloud.url.params=prepStmtCacheSize=517=true=sql_mode='STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION'

# CloudStack database SSL settings
db.cloud.useSSL=true
db.cloud.keyStore=/etc/ssl/certs/mariadb/clst01.keystore
db.cloud.keyStorePassword=
db.cloud.trustStore=/etc/ssl/certs/mariadb/clst.truststore
db.cloud.trustStorePassword=
db.cloud.keyStorePassphrase=vmops.com

# Encryption Settings
db.cloud.encryption.type=file
db.cloud.encrypt.secret=ENC()

# usage database settings
db.usage.username=cloud
db.usage.password=ENC()
db.usage.host=csdb-cltr01.cloud.local
db.usage.driver=jdbc:mysql
db.usage.port=3306
db.usage.name=cloud_usage

# usage database tuning parameters
db.usage.maxActive=100
db.usage.maxIdle=30
db.usage.maxWait=1
db.usage.url.params=

# Simulator database settings
db.simulator.username=cloud
db.simulator.password=cloud
db.simulator.host=localhost
db.simulator.driver=jdbc:mysql
db.simulator.port=3306
db.simulator.name=simulator
db.simulator.maxActive=250
db.simulator.maxIdle=30
db.simulator.maxWait=1
db.simulator.autoReconnect=true


# High Availability And Cluster Properties
db.ha.enabled=false
db.ha.loadBalanceStrategy=com.cloud.utils.db.StaticStrategy
# cloud stack Database
db.cloud.slaves=localhost,localhost
db.cloud.autoReconnect=true
db.cloud.failOverReadOnly=false
db.cloud.reconnectAtTxEnd=true
db.cloud.autoReconnectForPools=true
db.cloud.secondsBeforeRetryMaster=3600
db.cloud.queriesBeforeRetryMaster=5000
db.cloud.initialTimeout=3600

#usage Database
db.usage.slaves=localhost,localhost
db.usage.autoReconnect=true
db.usage.failOverReadOnly=false
db.usage.reconnectAtTxEnd=true
db.usage.autoReconnectForPools=true
db.usage.secondsBeforeRetryMaster=3600
db.usage.queriesBeforeRetryMaster=5000
db.usage.initialTimeout=3600

On Tue, Nov 21, 2017 at 12:46 PM, Rohit Yadav  wrote:
> Alireza,
>
>
> Can you share your db.properties file (you may replace password/ips with 
> dummy ones)?
>
>
> - Rohit
>
> 
> From: Ivan Kudryavtsev 
> Sent: Tuesday, November 21, 2017 2:32:50 PM
> To: dev@cloudstack.apache.org
> Subject: Re: No database selected for the transaction
>
> Also, have seen that with 4.10 with two management servers on one of them.
>
> 21 нояб. 2017 г. 3:36 ПП пользователь "Alireza Eskandari" <
> astro.alir...@gmail.com> написал:
>
>> Hi all,
>> I'm using a cluster of CS 4.9.3 with 2 nodes.
>> After couple of weeks, I get "No database selected for the
>> transaction" error in logs and I have to restart the CS services to
>> resolve the issue.
>> Could you help me about it?
>>
>> Here is the logs:
>>
>> 2017-11-21 10:37:35,641 WARN  [c.c.c.d.ManagementServerHostDaoImpl]
>> (Cluster-Heartbeat-1:ctx-a32c78be) (logid:c9227f75) Unexpected
>> exception,
>> com.cloud.utils.exception.CloudRuntimeException: No database selected
>> for the transaction
>> at com.cloud.utils.db.TransactionLegacy.getConnection(
>> TransactionLegacy.java:580)
>> at com.cloud.utils.db.TransactionLegacy.prepareStatement(
>> TransactionLegacy.java:467)
>> at com.cloud.utils.db.TransactionLegacy.prepareAutoCloseStatement(
>> TransactionLegacy.java:460)
>> at com.cloud.cluster.dao.ManagementServerHostDaoImpl.update(
>> ManagementServerHostDaoImpl.java:134)
>> at sun.reflect.GeneratedMethodAccessor76.invoke(Unknown Source)
>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(
>> DelegatingMethodAccessorImpl.java:43)
>> at java.lang.reflect.Method.invoke(Method.java:606)
>> at org.springframework.aop.support.AopUtils.
>> invokeJoinpointUsingReflection(AopUtils.java:317)
>> at org.springframework.aop.framework.ReflectiveMethodInvocation.
>> invokeJoinpoint(ReflectiveMethodInvocation.java:183)
>> at org.springframework.aop.framework.ReflectiveMethodInvocation.
>> proceed(ReflectiveMethodInvocation.java:150)
>> at com.cloud.utils.db.TransactionContextInterceptor.invoke(
>> 

Re: egress fw problems in 4.10?

[Nux!]

Rohit,

I see it accepts 0.0.0.0/0 on the source CIDR, but then transforms that into 
10.1.1.0/24 (or whatever), I'd imagine it could do the same with the 
destination CIDR and just "rename" 0.0.0.0/0 into 0.0.0.0/1.
However this is not a Cloudstack problem as I see it, it's an ipset 
bug/feature, so we should just "deal with it", perhaps update the documentation 
at least.

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
> From: "Rohit Yadav" 
> To: "dev" 
> Sent: Tuesday, 21 November, 2017 09:23:00
> Subject: Re: egress fw problems in 4.10?

> I hit the same issue with the debian9-systemvmtemplate PR. Earlier, the egress
> traffic option used to accept 0.0.0.0/0.
> 
> 
> - Rohit
> 
> 
> From: Nux! 
> Sent: Friday, November 17, 2017 11:09:26 PM
> To: dev
> Subject: Re: egress fw problems in 4.10?
> 
> Thanks Jayapal,
> 
> Indeed, I checked and 0.0.0.0/0 is not there. When I tried to add it manually 
> I
> got an error:
> ipset v6.12.1: The value of the CIDR parameter of the IP address is invalid
> 
> 
> Hash:net types will not accept 0 prefix, it's happy to accept 0.0.0.0/1 
> though,
> however I still can't do any egress except for ICMP ping for some reason.
> 
> If I omit specifying a a dest CIDR, then I get trully unrestricted egress.
> 
> I need to investigate some more when I get time, something's fishy.
> 
> --
> Sent from the Delta quadrant using Borg technology!
> 
> Nux!
> www.nux.ro
> 
> 
> rohit.ya...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
>  
> 
> 
> - Original Message -
>> From: "Jayapal Uradi" 
>> To: "dev" 
>> Sent: Friday, 17 November, 2017 04:02:13
>> Subject: Re: egress fw problems in 4.10?
> 
>> Hi Nux,
>>
>> I think the the ipset for destination cidr is not configured with 0.0.0.0/0 
>> due
>> this you might see this issue.
>> Please check the ipset and iptables rules once.
>>
>> iptables -L -nv
>> ipset -L
>>
>> Thanks,
>> Jayapal
>>
>>
>>> On Nov 17, 2017, a t 6:55 AM, Nux!  wrote:
>>>
>>> Hi,
>>>
>>> Just installed 4.10 today for a demo, but seems there are some problems 
>>> with the
>>> egress rules in isolated networks.
>>> Is there anything wrong with this rule? ACS allows me to add it, but no 
>>> outbound
>>> traffic is allowed at all.
>>>
>>> 10.1.1.0/24  0.0.0.0/0   All All All
>>>
>>> http://img.nux.ro/gL3-Selection_002.png
>>>
>>> If I replace 0.0.0.0/0 with a certain IP/32, then traffic works.
>>>
>>>
>>> Also, if I don't mention a destination cidr at all, outbound traffic also 
>>> works,
>>> but the docs state 0.0.0.0/0 should be honoured as valid destination cidr.
>>>
>>> Any ideas? I know there was recent work done on egress recently, maybe 
>>> related
>>> to that?
>>>
>>> Lucian
>>>
>>> --
>>> Sent from the Delta quadrant using Borg technology!
>>>
>>> Nux!
>>> www.nux.ro
>>
>> DISCLAIMER
>> ==
>> This e-mail may contain privileged and confidential information which is the
>> property of Accelerite, a Persistent Systems business. It is intended only 
>> for
>> the use of the individual or entity to which it is addressed. If you are not
>> the intended recipient, you are not authorized to read, retain, copy, print,
>> distribute or use this message. If you have received this communication in
>> error, please notify the sender and delete all copies of this message.
>> Accelerite, a Persistent Systems business does not accept any liability for
> > virus infected mails.

Re: egress fw problems in 4.10?

[Rohit Yadav]

I hit the same issue with the debian9-systemvmtemplate PR. Earlier, the egress 
traffic option used to accept 0.0.0.0/0.


- Rohit


From: Nux! 
Sent: Friday, November 17, 2017 11:09:26 PM
To: dev
Subject: Re: egress fw problems in 4.10?

Thanks Jayapal,

Indeed, I checked and 0.0.0.0/0 is not there. When I tried to add it manually I 
got an error:
ipset v6.12.1: The value of the CIDR parameter of the IP address is invalid


Hash:net types will not accept 0 prefix, it's happy to accept 0.0.0.0/1 though, 
however I still can't do any egress except for ICMP ping for some reason.

If I omit specifying a a dest CIDR, then I get trully unrestricted egress.

I need to investigate some more when I get time, something's fishy.

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro


rohit.ya...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
  
 

- Original Message -
> From: "Jayapal Uradi" 
> To: "dev" 
> Sent: Friday, 17 November, 2017 04:02:13
> Subject: Re: egress fw problems in 4.10?

> Hi Nux,
>
> I think the the ipset for destination cidr is not configured with 0.0.0.0/0 
> due
> this you might see this issue.
> Please check the ipset and iptables rules once.
>
> iptables -L -nv
> ipset -L
>
> Thanks,
> Jayapal
>
>
>> On Nov 17, 2017, a t 6:55 AM, Nux!  wrote:
>>
>> Hi,
>>
>> Just installed 4.10 today for a demo, but seems there are some problems with 
>> the
>> egress rules in isolated networks.
>> Is there anything wrong with this rule? ACS allows me to add it, but no 
>> outbound
>> traffic is allowed at all.
>>
>> 10.1.1.0/24  0.0.0.0/0   All All All
>>
>> http://img.nux.ro/gL3-Selection_002.png
>>
>> If I replace 0.0.0.0/0 with a certain IP/32, then traffic works.
>>
>>
>> Also, if I don't mention a destination cidr at all, outbound traffic also 
>> works,
>> but the docs state 0.0.0.0/0 should be honoured as valid destination cidr.
>>
>> Any ideas? I know there was recent work done on egress recently, maybe 
>> related
>> to that?
>>
>> Lucian
>>
>> --
>> Sent from the Delta quadrant using Borg technology!
>>
>> Nux!
>> www.nux.ro
>
> DISCLAIMER
> ==
> This e-mail may contain privileged and confidential information which is the
> property of Accelerite, a Persistent Systems business. It is intended only for
> the use of the individual or entity to which it is addressed. If you are not
> the intended recipient, you are not authorized to read, retain, copy, print,
> distribute or use this message. If you have received this communication in
> error, please notify the sender and delete all copies of this message.
> Accelerite, a Persistent Systems business does not accept any liability for
> virus infected mails.

Re: No database selected for the transaction

[Rohit Yadav]

Alireza,


Can you share your db.properties file (you may replace password/ips with dummy 
ones)?


- Rohit


From: Ivan Kudryavtsev 
Sent: Tuesday, November 21, 2017 2:32:50 PM
To: dev@cloudstack.apache.org
Subject: Re: No database selected for the transaction

Also, have seen that with 4.10 with two management servers on one of them.

21 нояб. 2017 г. 3:36 ПП пользователь "Alireza Eskandari" <
astro.alir...@gmail.com> написал:

> Hi all,
> I'm using a cluster of CS 4.9.3 with 2 nodes.
> After couple of weeks, I get "No database selected for the
> transaction" error in logs and I have to restart the CS services to
> resolve the issue.
> Could you help me about it?
>
> Here is the logs:
>
> 2017-11-21 10:37:35,641 WARN  [c.c.c.d.ManagementServerHostDaoImpl]
> (Cluster-Heartbeat-1:ctx-a32c78be) (logid:c9227f75) Unexpected
> exception,
> com.cloud.utils.exception.CloudRuntimeException: No database selected
> for the transaction
> at com.cloud.utils.db.TransactionLegacy.getConnection(
> TransactionLegacy.java:580)
> at com.cloud.utils.db.TransactionLegacy.prepareStatement(
> TransactionLegacy.java:467)
> at com.cloud.utils.db.TransactionLegacy.prepareAutoCloseStatement(
> TransactionLegacy.java:460)
> at com.cloud.cluster.dao.ManagementServerHostDaoImpl.update(
> ManagementServerHostDaoImpl.java:134)
> at sun.reflect.GeneratedMethodAccessor76.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(
> DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.springframework.aop.support.AopUtils.
> invokeJoinpointUsingReflection(AopUtils.java:317)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.
> invokeJoinpoint(ReflectiveMethodInvocation.java:183)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.
> proceed(ReflectiveMethodInvocation.java:150)
> at com.cloud.utils.db.TransactionContextInterceptor.invoke(
> TransactionContextInterceptor.java:34)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.
> proceed(ReflectiveMethodInvocation.java:161)
> at org.springframework.aop.interceptor.
> ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.
> proceed(ReflectiveMethodInvocation.java:172)
> at org.springframework.aop.framework.JdkDynamicAopProxy.
> invoke(JdkDynamicAopProxy.java:204)
> at com.sun.proxy.$Proxy201.update(Unknown Source)
> at com.cloud.cluster.ClusterManagerImpl$4.runInContext(
> ClusterManagerImpl.java:554)
> at org.apache.cloudstack.managed.context.
> ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
> at org.apache.cloudstack.managed.context.impl.
> DefaultManagedContext$1.call(DefaultManagedContext.java:56)
> at org.apache.cloudstack.managed.context.impl.
> DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
> at org.apache.cloudstack.managed.context.impl.
> DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
> at org.apache.cloudstack.managed.context.
> ManagedContextRunnable.run(ManagedContextRunnable.java:46)
> at java.util.concurrent.Executors$RunnableAdapter.
> call(Executors.java:473)
> at java.util.concurrent.FutureTask.runAndReset(
> FutureTask.java:304)
> at java.util.concurrent.ScheduledThreadPoolExecutor$
> ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178)
> at java.util.concurrent.ScheduledThreadPoolExecutor$
> ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(
> ThreadPoolExecutor.java:1152)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(
> ThreadPoolExecutor.java:622)
> at java.lang.Thread.run(Thread.java:748)
> 2017-11-21 10:37:35,641 ERROR [c.c.c.ClusterManagerImpl]
> (Cluster-Heartbeat-1:ctx-a32c78be) (logid:c9227f75) Unexpected
> exception in cluster heartbeat
> java.lang.RuntimeException: No database selected for the transaction
> at com.cloud.cluster.dao.ManagementServerHostDaoImpl.update(
> ManagementServerHostDaoImpl.java:148)
> at sun.reflect.GeneratedMethodAccessor76.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(
> DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.springframework.aop.support.AopUtils.
> invokeJoinpointUsingReflection(AopUtils.java:317)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.
> invokeJoinpoint(ReflectiveMethodInvocation.java:183)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.
> proceed(ReflectiveMethodInvocation.java:150)
> at 

Re: No database selected for the transaction

[Ivan Kudryavtsev]

Also, have seen that with 4.10 with two management servers on one of them.

21 нояб. 2017 г. 3:36 ПП пользователь "Alireza Eskandari" <
astro.alir...@gmail.com> написал:

> Hi all,
> I'm using a cluster of CS 4.9.3 with 2 nodes.
> After couple of weeks, I get "No database selected for the
> transaction" error in logs and I have to restart the CS services to
> resolve the issue.
> Could you help me about it?
>
> Here is the logs:
>
> 2017-11-21 10:37:35,641 WARN  [c.c.c.d.ManagementServerHostDaoImpl]
> (Cluster-Heartbeat-1:ctx-a32c78be) (logid:c9227f75) Unexpected
> exception,
> com.cloud.utils.exception.CloudRuntimeException: No database selected
> for the transaction
> at com.cloud.utils.db.TransactionLegacy.getConnection(
> TransactionLegacy.java:580)
> at com.cloud.utils.db.TransactionLegacy.prepareStatement(
> TransactionLegacy.java:467)
> at com.cloud.utils.db.TransactionLegacy.prepareAutoCloseStatement(
> TransactionLegacy.java:460)
> at com.cloud.cluster.dao.ManagementServerHostDaoImpl.update(
> ManagementServerHostDaoImpl.java:134)
> at sun.reflect.GeneratedMethodAccessor76.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(
> DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.springframework.aop.support.AopUtils.
> invokeJoinpointUsingReflection(AopUtils.java:317)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.
> invokeJoinpoint(ReflectiveMethodInvocation.java:183)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.
> proceed(ReflectiveMethodInvocation.java:150)
> at com.cloud.utils.db.TransactionContextInterceptor.invoke(
> TransactionContextInterceptor.java:34)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.
> proceed(ReflectiveMethodInvocation.java:161)
> at org.springframework.aop.interceptor.
> ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.
> proceed(ReflectiveMethodInvocation.java:172)
> at org.springframework.aop.framework.JdkDynamicAopProxy.
> invoke(JdkDynamicAopProxy.java:204)
> at com.sun.proxy.$Proxy201.update(Unknown Source)
> at com.cloud.cluster.ClusterManagerImpl$4.runInContext(
> ClusterManagerImpl.java:554)
> at org.apache.cloudstack.managed.context.
> ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
> at org.apache.cloudstack.managed.context.impl.
> DefaultManagedContext$1.call(DefaultManagedContext.java:56)
> at org.apache.cloudstack.managed.context.impl.
> DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
> at org.apache.cloudstack.managed.context.impl.
> DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
> at org.apache.cloudstack.managed.context.
> ManagedContextRunnable.run(ManagedContextRunnable.java:46)
> at java.util.concurrent.Executors$RunnableAdapter.
> call(Executors.java:473)
> at java.util.concurrent.FutureTask.runAndReset(
> FutureTask.java:304)
> at java.util.concurrent.ScheduledThreadPoolExecutor$
> ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178)
> at java.util.concurrent.ScheduledThreadPoolExecutor$
> ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(
> ThreadPoolExecutor.java:1152)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(
> ThreadPoolExecutor.java:622)
> at java.lang.Thread.run(Thread.java:748)
> 2017-11-21 10:37:35,641 ERROR [c.c.c.ClusterManagerImpl]
> (Cluster-Heartbeat-1:ctx-a32c78be) (logid:c9227f75) Unexpected
> exception in cluster heartbeat
> java.lang.RuntimeException: No database selected for the transaction
> at com.cloud.cluster.dao.ManagementServerHostDaoImpl.update(
> ManagementServerHostDaoImpl.java:148)
> at sun.reflect.GeneratedMethodAccessor76.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(
> DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.springframework.aop.support.AopUtils.
> invokeJoinpointUsingReflection(AopUtils.java:317)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.
> invokeJoinpoint(ReflectiveMethodInvocation.java:183)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.
> proceed(ReflectiveMethodInvocation.java:150)
> at com.cloud.utils.db.TransactionContextInterceptor.invoke(
> TransactionContextInterceptor.java:34)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.
> proceed(ReflectiveMethodInvocation.java:161)
> at org.springframework.aop.interceptor.
> ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
>   

No database selected for the transaction

[Alireza Eskandari]

Hi all,
I'm using a cluster of CS 4.9.3 with 2 nodes.
After couple of weeks, I get "No database selected for the
transaction" error in logs and I have to restart the CS services to
resolve the issue.
Could you help me about it?

Here is the logs:

2017-11-21 10:37:35,641 WARN  [c.c.c.d.ManagementServerHostDaoImpl]
(Cluster-Heartbeat-1:ctx-a32c78be) (logid:c9227f75) Unexpected
exception,
com.cloud.utils.exception.CloudRuntimeException: No database selected
for the transaction
at 
com.cloud.utils.db.TransactionLegacy.getConnection(TransactionLegacy.java:580)
at 
com.cloud.utils.db.TransactionLegacy.prepareStatement(TransactionLegacy.java:467)
at 
com.cloud.utils.db.TransactionLegacy.prepareAutoCloseStatement(TransactionLegacy.java:460)
at 
com.cloud.cluster.dao.ManagementServerHostDaoImpl.update(ManagementServerHostDaoImpl.java:134)
at sun.reflect.GeneratedMethodAccessor76.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at 
com.cloud.utils.db.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:34)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
at 
org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at 
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at com.sun.proxy.$Proxy201.update(Unknown Source)
at 
com.cloud.cluster.ClusterManagerImpl$4.runInContext(ClusterManagerImpl.java:554)
at 
org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
at 
org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:473)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1152)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:622)
at java.lang.Thread.run(Thread.java:748)
2017-11-21 10:37:35,641 ERROR [c.c.c.ClusterManagerImpl]
(Cluster-Heartbeat-1:ctx-a32c78be) (logid:c9227f75) Unexpected
exception in cluster heartbeat
java.lang.RuntimeException: No database selected for the transaction
at 
com.cloud.cluster.dao.ManagementServerHostDaoImpl.update(ManagementServerHostDaoImpl.java:148)
at sun.reflect.GeneratedMethodAccessor76.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at 
com.cloud.utils.db.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:34)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
at 
org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at 
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at com.sun.proxy.$Proxy201.update(Unknown Source)
at