Re: Getting a strange error

[Simon Weller]

Anything in the logs indicating it lost connection? You might have to grab mgmt 
logs to and see what triggers it.



From: Marty Godsey 
Sent: Wednesday, October 12, 2016 4:54 PM
To: users@cloudstack.apache.org
Subject: RE: Getting a strange error

Very little. Almost no CPU usage and 500M/1G RAM.. no disk activity.

The console is actually not used a lot.

Regards,
Marty Godsey

-Original Message-
From: Simon Weller [mailto:swel...@ena.com]
Sent: Wednesday, October 12, 2016 5:11 PM
To: users@cloudstack.apache.org
Subject: Re: Getting a strange error

Log into it and check memory/disk utilization.



From: Marty Godsey 
Sent: Wednesday, October 12, 2016 4:04 PM
To: users@cloudstack.apache.org
Subject: RE: Getting a strange error

I checked this table and it shows it as "Up" but I still receive this error.. 
Anywhere else I should look.

Regards,
Marty Godsey

-Original Message-
From: Simon Weller [mailto:swel...@ena.com]
Sent: Wednesday, October 12, 2016 9:51 AM
To: users@cloudstack.apache.org
Subject: Re: Getting a strange error

Marty,


The SSVM and CPVM have agents running on them. I believe they are identified as 
a host by ACS management.

Check your host table in MySQL and see if it give you any more information.


- Si


From: Marty Godsey 
Sent: Tuesday, October 11, 2016 11:09 PM
To: users@cloudstack.apache.org
Subject: Getting a strange error

I am receiving this error every few hours but the strange thing is, it's not a 
host, it's a console proxy. The Proxy works fine.


In availability zone 1, host is in alert state: 18-v-713-VM

Any one seen this? Also the name of the console proxy is not 18-v-713-VM  it is 
v-713-VM.

Regards,
Marty Godsey

RE: Getting a strange error

[Marty Godsey]

Very little. Almost no CPU usage and 500M/1G RAM.. no disk activity.

The console is actually not used a lot.

Regards,
Marty Godsey

-Original Message-
From: Simon Weller [mailto:swel...@ena.com] 
Sent: Wednesday, October 12, 2016 5:11 PM
To: users@cloudstack.apache.org
Subject: Re: Getting a strange error

Log into it and check memory/disk utilization.



From: Marty Godsey 
Sent: Wednesday, October 12, 2016 4:04 PM
To: users@cloudstack.apache.org
Subject: RE: Getting a strange error

I checked this table and it shows it as "Up" but I still receive this error.. 
Anywhere else I should look.

Regards,
Marty Godsey

-Original Message-
From: Simon Weller [mailto:swel...@ena.com]
Sent: Wednesday, October 12, 2016 9:51 AM
To: users@cloudstack.apache.org
Subject: Re: Getting a strange error

Marty,


The SSVM and CPVM have agents running on them. I believe they are identified as 
a host by ACS management.

Check your host table in MySQL and see if it give you any more information.


- Si


From: Marty Godsey 
Sent: Tuesday, October 11, 2016 11:09 PM
To: users@cloudstack.apache.org
Subject: Getting a strange error

I am receiving this error every few hours but the strange thing is, it's not a 
host, it's a console proxy. The Proxy works fine.


In availability zone 1, host is in alert state: 18-v-713-VM

Any one seen this? Also the name of the console proxy is not 18-v-713-VM  it is 
v-713-VM.

Regards,
Marty Godsey

Re: Getting a strange error

[Simon Weller]

Log into it and check memory/disk utilization.



From: Marty Godsey 
Sent: Wednesday, October 12, 2016 4:04 PM
To: users@cloudstack.apache.org
Subject: RE: Getting a strange error

I checked this table and it shows it as "Up" but I still receive this error.. 
Anywhere else I should look.

Regards,
Marty Godsey

-Original Message-
From: Simon Weller [mailto:swel...@ena.com]
Sent: Wednesday, October 12, 2016 9:51 AM
To: users@cloudstack.apache.org
Subject: Re: Getting a strange error

Marty,


The SSVM and CPVM have agents running on them. I believe they are identified as 
a host by ACS management.

Check your host table in MySQL and see if it give you any more information.


- Si


From: Marty Godsey 
Sent: Tuesday, October 11, 2016 11:09 PM
To: users@cloudstack.apache.org
Subject: Getting a strange error

I am receiving this error every few hours but the strange thing is, it's not a 
host, it's a console proxy. The Proxy works fine.


In availability zone 1, host is in alert state: 18-v-713-VM

Any one seen this? Also the name of the console proxy is not 18-v-713-VM  it is 
v-713-VM.

Regards,
Marty Godsey

RE: Getting a strange error

[Marty Godsey]

I checked this table and it shows it as "Up" but I still receive this error.. 
Anywhere else I should look.

Regards,
Marty Godsey

-Original Message-
From: Simon Weller [mailto:swel...@ena.com] 
Sent: Wednesday, October 12, 2016 9:51 AM
To: users@cloudstack.apache.org
Subject: Re: Getting a strange error

Marty,


The SSVM and CPVM have agents running on them. I believe they are identified as 
a host by ACS management.

Check your host table in MySQL and see if it give you any more information.


- Si


From: Marty Godsey 
Sent: Tuesday, October 11, 2016 11:09 PM
To: users@cloudstack.apache.org
Subject: Getting a strange error

I am receiving this error every few hours but the strange thing is, it's not a 
host, it's a console proxy. The Proxy works fine.


In availability zone 1, host is in alert state: 18-v-713-VM

Any one seen this? Also the name of the console proxy is not 18-v-713-VM  it is 
v-713-VM.

Regards,
Marty Godsey

Long downtimes for VMs through automatically triggered storage migration

[Melanie Desaive]

Hi all,

my college and I are having a dispute on when cloudstack should
automatically trigger storage migrations and what options we have to
control cloudstacks behavior in terms of storage migrations.

We are operating a setup with two XenServer clusters which are combined
into one pod. Each cluster with its own independent SRs of type lvmoiscsi.

Unfortunately we had a XenServer bug, which prevented a few VMs to start
on any compute node. Any time this bug appeared, CloudStack tried to
start the concerned VM successively on each node of the actual cluster
and afterwards started a storage migration to the second cluster.

We are using UserDispersing deployment planner.

The decision of the deployment planner to start the storage migration
was very unfortunate for us. Mainly because:
 * We are operating some VMs with big data volumes which where
inaccessible for the time the storage migration was running.
 * The SR on the destination cluster did not even have the capacity to
take all volumes of the big VMs. Still the migration was triggered.

We would like to have some kind of best practice advice on how other are
preventing long, unplanned downtimes for VMs with huge data volumes
through automated storage migration.

We discussed the topic and came up with the following questions:
 * Is the described behaviour of the deployment planner intentional?
 * Is it possible to prevent some few VMs with huge storage volumes from
automated storage migration and what would be the best way to achieve
this? Could we use storage or host tags for this purpose?
 * Is it possible to globally prevent the deployment planner from
starting storage migrations?
* Are there global settings to achieve this?
* Would we have to adapt the deployment planner?
 * Do we have to rethink our system architecture and avoid huge data
volumes completely?
 * Was the decision to put two clusters into one pod a bad idea?
 * Are there other solutions to our problem?

We would greatly appreciate any advice in the issue!

Best regards,

Melanie

-- 
--

Heinlein Support GmbH
Linux: Akademie - Support - Hosting

http://www.heinlein-support.de
Tel: 030 / 40 50 51 - 0
Fax: 030 / 40 50 51 - 19

Zwangsangaben lt. §35a GmbHG:
HRB 93818 B / Amtsgericht Berlin-Charlottenburg,
Geschäftsführer: Peer Heinlein  -- Sitz: Berlin

Re: Link Domain to LDAP

[Rajani Karuturi]

Yes, you can have LDAP configured at global and domain level.
Did you give fully qualified name of GROUP/OU while linking?

Easiest way to debug is to run the ldap query manually and see if
it returns any results
ldapsearch -x -h hostname -p port "basedn" -s sub -D "username"
-w password
"(&(objectClass=user)(sAMAccountName=*)(memberof=linked_group_name))"

Also check that `ldap.provider` is set to correct value and there
are direct users in the group.
Nested groups will only work with MicrosoftAD provider and with
configuration `ldap.nested.groups.enable` set to true.

There is a demo of the feature at
https://youtu.be/GI9b9MiOQkw?t=4m10s

Thanks,
~ Rajani
http://cloudplatform.accelerite.com/

On October 12, 2016 at 6:23 AM, Marty Godsey
(ma...@gonsource.com) wrote:
Hello,

I have an ACS 4.9 instance that runs well with no issues. I have
enabled LDAP authentication at the Global Level and this works
without issue. The question I have is the "Link Domain to LDAP"
function at the domain level. I have a domain that I want to auto
sync. I added this sub domain ( lets call it ROOT/LDAPTest ) that
I configured with the DN of the group I am wanting to populate
from (I also attempted this with the OU setting as well) and the
user that was created cannot authenticate nor are any of the test
accounts in Active Directory being created in ACS.

I have LDAP configured globally and I also, as a test made the
user part of the group I indicated for "LDAP Accounts" and the
user shows up, but the "Link Domain to LDAP" does not seem to
work. I tried looking in the logs and did not see any error or
attempts to query Active Directory.

Is this a broken function? Can you have both globally set LDAP
settings and "Link Domain to LDAP" settings?

Regards,
Marty Godsey