[GitHub] cloudstack pull request: CLOUDSTACK-8688 - default policies for IN...

[karuturi]

Github user karuturi commented on the pull request:

https://github.com/apache/cloudstack/pull/765#issuecomment-136962555
  
tested this on Xen 6.5 advanced zone with isolated and VPC. verified that 
the default policies are set to drop. 

I am not sure if its related to this. But, I found the below issue
in case of vm launched in vpc, outgoing public traffic worked (I was able 
to ping google.com)
But, in case of default isolated 
network(DefaultIsolatedNetworkOfferingWithSourceNatService) vm, outgoing public 
traffic was blocked even after adding egress rule.
It only worked after running the following on isolated VR
```
iptables -I FW_OUTBOUND -j FIREWALL_EGRESS_RULES
```


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cloudstack pull request: CLOUDSTACK-8762: Check to confirm disk ac...

[bhaisaab]

Github user bhaisaab commented on the pull request:

https://github.com/apache/cloudstack/pull/754#issuecomment-136962823
  
@miguelaferreira @wilderrodrigues @wido @jburwell @abhinandanprateek 
@kishankavala hi, can you help review this, thanks


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cloudstack pull request: Cloudstack:8647 LDAP Trust AD and Autoimp...

[karuturi]

Github user karuturi commented on the pull request:

https://github.com/apache/cloudstack/pull/755#issuecomment-136980464
  
users are added based on the username. So, in this case LDAP user wont be 
added(it will error out). CS user will exist and will continue to work with 
earlier password using native authentication.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cloudstack pull request: CLOUDSTACK-8762: Check to confirm disk ac...

[karuturi]

Github user karuturi commented on the pull request:

https://github.com/apache/cloudstack/pull/754#issuecomment-136981967
  
@bhaisaab There are 2 reviews already. @wido and @miguelaferreira gave :+1: 
I think you can merge this and #753 


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Facing BOOT issues (if DATA drives are attached) on VMs in CCP 4.5.0

[anil lakineni]

Hi All,

We are facing boot issues when VMs have DATA drives.


*After VM was shut down we were unable to power on server unless we detach
Data Drive.*

We are using Citrix Cloud Portal 4.5.0 and XenServer 6.2

*Note: *We have not facing this issue on some of the VM's which also have
DATA drives but facing this kind of boot issue on only some VMs.

If any one would have this kind of issue, please let us know the persistent
solution to fix the issue.
Thanks in advance.

Regards,
Anil.

[GitHub] cloudstack pull request: Cloudstack:8647 LDAP Trust AD and Autoimp...

[koushik-das]

Github user koushik-das commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/755#discussion_r38511573
  
--- Diff: 
plugins/user-authenticators/ldap/src/org/apache/cloudstack/api/command/LinkDomainToLdapCmd.java
 ---
@@ -0,0 +1,114 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements.  See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership.  The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License.  You may obtain a copy of the License at
+ *
+ *   http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied.  See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.cloudstack.api.command;
+
+import javax.inject.Inject;
+
+import com.cloud.exception.InvalidParameterValueException;
+import com.cloud.user.AccountService;
+import com.cloud.user.User;
+import com.cloud.user.UserAccount;
+import org.apache.cloudstack.api.APICommand;
+import org.apache.cloudstack.api.ApiConstants;
+import org.apache.cloudstack.api.ApiErrorCode;
+import org.apache.cloudstack.api.BaseCmd;
+import org.apache.cloudstack.api.Parameter;
+import org.apache.cloudstack.api.ServerApiException;
+import org.apache.cloudstack.api.response.DomainResponse;
+import org.apache.cloudstack.api.response.LinkDomainToLdapResponse;
+import org.apache.cloudstack.ldap.LdapManager;
+import org.apache.cloudstack.ldap.LdapUser;
+import org.apache.cloudstack.ldap.NoLdapUserMatchingQueryException;
+import org.apache.log4j.Logger;
+
+import com.cloud.user.Account;
+
+import java.util.UUID;
+
+@APICommand(name = "linkDomainToLdap", description = "link an existing 
cloudstack domain to group or OU in ldap", responseObject = 
LinkDomainToLdapResponse.class, since = "4.6.0",
+requestHasSensitiveInfo = false, responseHasSensitiveInfo = false)
+public class LinkDomainToLdapCmd extends BaseCmd {
+public static final Logger s_logger = 
Logger.getLogger(LinkDomainToLdapCmd.class.getName());
+private static final String s_name = "linkdomaintoldapresponse";
+
+@Parameter(name = ApiConstants.DOMAIN_ID, type = CommandType.UUID, 
entityType = DomainResponse.class, description = "The id of the domain which 
has to be linked to LDAP.")
+private Long domainId;
+
+@Parameter(name = ApiConstants.TYPE, type = CommandType.STRING, 
required = true, description = "type of the ldap name. GROUP or OU")
+private String type;
+
+@Parameter(name = ApiConstants.NAME, type = CommandType.STRING, 
required = true, description = "name of the group or OU in LDAP")
+private String name;
+
+@Parameter(name = ApiConstants.ADMIN, type = CommandType.STRING, 
required = false, description = "domain admin username in LDAP ")
+private String admin;
+
+@Parameter(name = ApiConstants.ACCOUNT_TYPE, type = CommandType.SHORT, 
required = true, description = "Type of the account to auto import. Specify 0 
for user, 1 for root " +
+"admin, and 2 for domain admin")
+private short accountType;
+
+@Inject
+private LdapManager _ldapManager;
+
+@Inject
+public AccountService _accountService;
+
+@Override
+public void execute() throws ServerApiException {
+try {
+LinkDomainToLdapResponse response = 
_ldapManager.linkDomainToLdap(domainId, type, name, accountType);
--- End diff --

The api semantics doesn't seem right here. It is ok for createUserAccount 
to fail if the user exists but in that case the response should have the UUID 
of the existing account. Also if the user doesn't exist but still the call 
fails then the entire API should fail, a tx would help in this case. The 
semantics should be if optional admin user parameter is specified then the 
admin UUID should always be present in the response in case of success 
otherwise the API call should return failure.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cloudstack pull request: Cloudstack:8647 LDAP Trust AD and Autoimp...

[koushik-das]

Github user koushik-das commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/755#discussion_r38511898
  
--- Diff: 
plugins/user-authenticators/ldap/src/org/apache/cloudstack/ldap/LdapAuthenticator.java
 ---
@@ -52,21 +58,71 @@ public LdapAuthenticator(final LdapManager ldapManager, 
final UserAccountDao use
 return new Pair(false, 
null);
 }
 
-final UserAccount user = _userAccountDao.getUserAccount(username, 
domainId);
+boolean result = false;
+ActionOnFailedAuthentication action = null;
 
-if (user == null) {
-s_logger.debug("Unable to find user with " + username + " in 
domain " + domainId);
-return new Pair(false, 
null);
-} else if (_ldapManager.isLdapEnabled()) {
-boolean result = _ldapManager.canAuthenticate(username, 
password);
-ActionOnFailedAuthentication action = null;
-if (result == false) {
+if (_ldapManager.isLdapEnabled()) {
+final UserAccount user = 
_userAccountDao.getUserAccount(username, domainId);
+LdapTrustMapVO ldapTrustMapVO = 
_ldapManager.getDomainLinkedToLdap(domainId);
+if(ldapTrustMapVO != null) {
+try {
+LdapUser ldapUser = _ldapManager.getUser(username, 
ldapTrustMapVO.getType().toString(), ldapTrustMapVO.getName());
+if(!ldapUser.isDisabled()) {
+result = 
_ldapManager.canAuthenticate(ldapUser.getPrincipal(), password);
+if(result) {
+if(user == null) {
+// import user to cloudstack
+createCloudStackUserAccount(ldapUser, 
domainId, ldapTrustMapVO.getAccountType());
--- End diff --

In this case as well, the authn is successful but user sees failure as 
account creation has failed. The behaviour is not intuitive. If it is difficult 
to address it in implementation then should be documented as limitation.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cloudstack pull request: Cloudstack:8647 LDAP Trust AD and Autoimp...

[koushik-das]

Github user koushik-das commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/755#discussion_r38511940
  
--- Diff: 
plugins/user-authenticators/ldap/src/org/apache/cloudstack/ldap/LdapAuthenticator.java
 ---
@@ -52,21 +58,71 @@ public LdapAuthenticator(final LdapManager ldapManager, 
final UserAccountDao use
 return new Pair(false, 
null);
 }
 
-final UserAccount user = _userAccountDao.getUserAccount(username, 
domainId);
+boolean result = false;
+ActionOnFailedAuthentication action = null;
 
-if (user == null) {
-s_logger.debug("Unable to find user with " + username + " in 
domain " + domainId);
-return new Pair(false, 
null);
-} else if (_ldapManager.isLdapEnabled()) {
-boolean result = _ldapManager.canAuthenticate(username, 
password);
-ActionOnFailedAuthentication action = null;
-if (result == false) {
+if (_ldapManager.isLdapEnabled()) {
+final UserAccount user = 
_userAccountDao.getUserAccount(username, domainId);
+LdapTrustMapVO ldapTrustMapVO = 
_ldapManager.getDomainLinkedToLdap(domainId);
+if(ldapTrustMapVO != null) {
+try {
+LdapUser ldapUser = _ldapManager.getUser(username, 
ldapTrustMapVO.getType().toString(), ldapTrustMapVO.getName());
+if(!ldapUser.isDisabled()) {
+result = 
_ldapManager.canAuthenticate(ldapUser.getPrincipal(), password);
+if(result) {
+if(user == null) {
+// import user to cloudstack
+createCloudStackUserAccount(ldapUser, 
domainId, ldapTrustMapVO.getAccountType());
--- End diff --

In this case as well, the authn is successful but user sees failure as 
account creation has failed. The behaviour is not intuitive. If it is difficult 
to address it in implementation then should be documented as limitation.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cloudstack pull request: Cloudstack:8647 LDAP Trust AD and Autoimp...

[koushik-das]

Github user koushik-das commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/755#discussion_r38512226
  
--- Diff: server/src/com/cloud/user/AccountManagerImpl.java ---
@@ -2145,14 +2145,10 @@ private UserAccount getUserAccount(String username, 
String password, Long domain
 s_logger.debug("Attempting to log in user: " + username + " in 
domain " + domainId);
 }
 UserAccount userAccount = _userAccountDao.getUserAccount(username, 
domainId);
-if (userAccount == null) {
-s_logger.warn("Unable to find an user with username " + 
username + " in domain " + domainId);
-return null;
-}
 
 boolean authenticated = false;
 HashSet actionsOnFailedAuthenticaion 
= new HashSet();
-User.Source userSource = userAccount.getSource();
+User.Source userSource = userAccount != null ? 
userAccount.getSource(): User.Source.UNKNOWN;
--- End diff --

Think about it from the perspective of authenticators. Can a new 
authenticator break this logic?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cloudstack pull request: Cloudstack:8647 LDAP Trust AD and Autoimp...

[karuturi]

Github user karuturi commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/755#discussion_r38512312
  
--- Diff: 
plugins/user-authenticators/ldap/src/org/apache/cloudstack/ldap/LdapAuthenticator.java
 ---
@@ -52,21 +58,71 @@ public LdapAuthenticator(final LdapManager ldapManager, 
final UserAccountDao use
 return new Pair(false, 
null);
 }
 
-final UserAccount user = _userAccountDao.getUserAccount(username, 
domainId);
+boolean result = false;
+ActionOnFailedAuthentication action = null;
 
-if (user == null) {
-s_logger.debug("Unable to find user with " + username + " in 
domain " + domainId);
-return new Pair(false, 
null);
-} else if (_ldapManager.isLdapEnabled()) {
-boolean result = _ldapManager.canAuthenticate(username, 
password);
-ActionOnFailedAuthentication action = null;
-if (result == false) {
+if (_ldapManager.isLdapEnabled()) {
+final UserAccount user = 
_userAccountDao.getUserAccount(username, domainId);
+LdapTrustMapVO ldapTrustMapVO = 
_ldapManager.getDomainLinkedToLdap(domainId);
+if(ldapTrustMapVO != null) {
+try {
+LdapUser ldapUser = _ldapManager.getUser(username, 
ldapTrustMapVO.getType().toString(), ldapTrustMapVO.getName());
+if(!ldapUser.isDisabled()) {
+result = 
_ldapManager.canAuthenticate(ldapUser.getPrincipal(), password);
+if(result) {
+if(user == null) {
+// import user to cloudstack
+createCloudStackUserAccount(ldapUser, 
domainId, ldapTrustMapVO.getAccountType());
--- End diff --

authentication wont be successful. authentication will fail as 
createuseraccount will throw exception.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cloudstack pull request: Cloudstack:8647 LDAP Trust AD and Autoimp...

[karuturi]

Github user karuturi commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/755#discussion_r38512420
  
--- Diff: 
plugins/user-authenticators/ldap/src/org/apache/cloudstack/api/command/LinkDomainToLdapCmd.java
 ---
@@ -0,0 +1,114 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements.  See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership.  The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License.  You may obtain a copy of the License at
+ *
+ *   http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied.  See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.cloudstack.api.command;
+
+import javax.inject.Inject;
+
+import com.cloud.exception.InvalidParameterValueException;
+import com.cloud.user.AccountService;
+import com.cloud.user.User;
+import com.cloud.user.UserAccount;
+import org.apache.cloudstack.api.APICommand;
+import org.apache.cloudstack.api.ApiConstants;
+import org.apache.cloudstack.api.ApiErrorCode;
+import org.apache.cloudstack.api.BaseCmd;
+import org.apache.cloudstack.api.Parameter;
+import org.apache.cloudstack.api.ServerApiException;
+import org.apache.cloudstack.api.response.DomainResponse;
+import org.apache.cloudstack.api.response.LinkDomainToLdapResponse;
+import org.apache.cloudstack.ldap.LdapManager;
+import org.apache.cloudstack.ldap.LdapUser;
+import org.apache.cloudstack.ldap.NoLdapUserMatchingQueryException;
+import org.apache.log4j.Logger;
+
+import com.cloud.user.Account;
+
+import java.util.UUID;
+
+@APICommand(name = "linkDomainToLdap", description = "link an existing 
cloudstack domain to group or OU in ldap", responseObject = 
LinkDomainToLdapResponse.class, since = "4.6.0",
+requestHasSensitiveInfo = false, responseHasSensitiveInfo = false)
+public class LinkDomainToLdapCmd extends BaseCmd {
+public static final Logger s_logger = 
Logger.getLogger(LinkDomainToLdapCmd.class.getName());
+private static final String s_name = "linkdomaintoldapresponse";
+
+@Parameter(name = ApiConstants.DOMAIN_ID, type = CommandType.UUID, 
entityType = DomainResponse.class, description = "The id of the domain which 
has to be linked to LDAP.")
+private Long domainId;
+
+@Parameter(name = ApiConstants.TYPE, type = CommandType.STRING, 
required = true, description = "type of the ldap name. GROUP or OU")
+private String type;
+
+@Parameter(name = ApiConstants.NAME, type = CommandType.STRING, 
required = true, description = "name of the group or OU in LDAP")
+private String name;
+
+@Parameter(name = ApiConstants.ADMIN, type = CommandType.STRING, 
required = false, description = "domain admin username in LDAP ")
+private String admin;
+
+@Parameter(name = ApiConstants.ACCOUNT_TYPE, type = CommandType.SHORT, 
required = true, description = "Type of the account to auto import. Specify 0 
for user, 1 for root " +
+"admin, and 2 for domain admin")
+private short accountType;
+
+@Inject
+private LdapManager _ldapManager;
+
+@Inject
+public AccountService _accountService;
+
+@Override
+public void execute() throws ServerApiException {
+try {
+LinkDomainToLdapResponse response = 
_ldapManager.linkDomainToLdap(domainId, type, name, accountType);
--- End diff --

I will see if I can change that later. For now, it will as documented in FS 
which is, it returns created account id when the account can be created. 
Otherwise, the information on why it failed to create the account will be in 
logs. 


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cloudstack pull request: Cloudstack:8647 LDAP Trust AD and Autoimp...

[koushik-das]

Github user koushik-das commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/755#discussion_r38512709
  
--- Diff: 
plugins/user-authenticators/ldap/src/org/apache/cloudstack/ldap/LdapManagerImpl.java
 ---
@@ -243,4 +263,22 @@ public boolean isLdapEnabled() {
 closeContext(context);
 }
 }
+
+@Override
+public LinkDomainToLdapResponse linkDomainToLdap(Long domainId, String 
type, String name, short accountType) {
+Validate.notNull(type, "type cannot be null. It should either be 
GROUP or OU");
+Validate.notNull(domainId, "domainId cannot be null.");
+Validate.notEmpty(name, "GROUP or OU name cannot be empty");
--- End diff --

This results in creation of more than one CS account (one under every 
domain) for a single AD account. I don't think this is desirable as it may lead 
to confusion. If there is a need to support this kind of a scenario then it 
should be properly documented and called out in the FS.

Personally I feel AD group/ou should be mapped to a single domain.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cloudstack pull request: CLOUDSTACK-8762: Check to confirm disk ac...

[bhaisaab]

Github user bhaisaab commented on the pull request:

https://github.com/apache/cloudstack/pull/754#issuecomment-136995082
  
Thanks @karuturi merging now


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cloudstack pull request: CLOUDSTACK-8762: Check to confirm disk ac...

[asfgit]

Github user asfgit closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cloudstack pull request: CLOUDSTACK-8762: Check to confirm disk ac...

[asfgit]

Github user asfgit closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cloudstack pull request: Cloudstack:8647 LDAP Trust AD and Autoimp...

[karuturi]

Github user karuturi commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/755#discussion_r38513021
  
--- Diff: server/src/com/cloud/user/AccountManagerImpl.java ---
@@ -2145,14 +2145,10 @@ private UserAccount getUserAccount(String username, 
String password, Long domain
 s_logger.debug("Attempting to log in user: " + username + " in 
domain " + domainId);
 }
 UserAccount userAccount = _userAccountDao.getUserAccount(username, 
domainId);
-if (userAccount == null) {
-s_logger.warn("Unable to find an user with username " + 
username + " in domain " + domainId);
-return null;
-}
 
 boolean authenticated = false;
 HashSet actionsOnFailedAuthenticaion 
= new HashSet();
-User.Source userSource = userAccount.getSource();
+User.Source userSource = userAccount != null ? 
userAccount.getSource(): User.Source.UNKNOWN;
--- End diff --

I checked that after the discussion yesterday. 
Every authenticator checks if a user exists in cloudstack. That 
responsibility is with the authenticator. In the earlier case, if the user 
doesnt exist, it throws a NPE on line 2155 which is a recent change. Prior to 
that change, any cloud provider can write an authenticator which always returns 
true even when cloudstack account doesnt exist. But, will break in lot of other 
places with NPEs as the rest of the app assumes logged in user has an account 
in cloudstack db. I think that needs to be fixed so that anyone can plugin 
their own user management system without using native cloudstack users.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cloudstack pull request: Cloudstack:8647 LDAP Trust AD and Autoimp...

[karuturi]

Github user karuturi commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/755#discussion_r38513100
  
--- Diff: 
plugins/user-authenticators/ldap/src/org/apache/cloudstack/ldap/LdapManagerImpl.java
 ---
@@ -243,4 +263,22 @@ public boolean isLdapEnabled() {
 closeContext(context);
 }
 }
+
+@Override
+public LinkDomainToLdapResponse linkDomainToLdap(Long domainId, String 
type, String name, short accountType) {
+Validate.notNull(type, "type cannot be null. It should either be 
GROUP or OU");
+Validate.notNull(domainId, "domainId cannot be null.");
+Validate.notEmpty(name, "GROUP or OU name cannot be empty");
--- End diff --

will update FS with this info.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cloudstack pull request: CLOUDSTACK-8678: Reserve RAM for KVM host...

[koushik-das]

Github user koushik-das commented on the pull request:

https://github.com/apache/cloudstack/pull/766#issuecomment-137004807
  
What happens in case of an upgrade? Looks like there is a possibility that 
the host may get over-provisioned. Should there be some scripts to let the user 
know if some VMs needs to be destroyed before upgrade?

Also do we need a similar behaviour for cpu?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Build failed in Jenkins: simulator-4.5-singlerun #271

[jenkins]

See 

--
Started by upstream project "build-4.5-simulator" build number 325
originally caused by:
 Started by upstream project "build-4.5" build number 523
 originally caused by:
  Started by an SCM change
[EnvInject] - Loading node environment variables.
Building remotely on simulator in workspace 

 > /usr/bin/git rev-parse --is-inside-work-tree # timeout=400
Fetching changes from the remote Git repository
 > /usr/bin/git config remote.origin.url 
 > https://git-wip-us.apache.org/repos/asf/cloudstack.git # timeout=400
Fetching upstream changes from 
https://git-wip-us.apache.org/repos/asf/cloudstack.git
 > /usr/bin/git --version # timeout=400
 > /usr/bin/git fetch --tags --progress 
 > https://git-wip-us.apache.org/repos/asf/cloudstack.git 
 > +refs/heads/*:refs/remotes/origin/*
ERROR: Error fetching remote repo 'origin'
hudson.plugins.git.GitException: Failed to fetch from 
https://git-wip-us.apache.org/repos/asf/cloudstack.git
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:735)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:983)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1016)
at hudson.scm.SCM.checkout(SCM.java:484)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1258)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:622)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:528)
at hudson.model.Run.execute(Run.java:1759)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:89)
at hudson.model.Executor.run(Executor.java:240)
Caused by: hudson.plugins.git.GitException: Command "/usr/bin/git fetch --tags 
--progress https://git-wip-us.apache.org/repos/asf/cloudstack.git 
+refs/heads/*:refs/remotes/origin/*" returned status code 128:
stdout: 
stderr: error:  while accessing 
https://git-wip-us.apache.org/repos/asf/cloudstack.git/info/refs

fatal: HTTP request failed

at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1591)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1379)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$300(CliGitAPIImpl.java:86)
at 
org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:324)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:152)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:145)
at hudson.remoting.UserRequest.perform(UserRequest.java:121)
at hudson.remoting.UserRequest.perform(UserRequest.java:49)
at hudson.remoting.Request$2.run(Request.java:324)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
at ..remote call to simulator(Native Method)
at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1356)
at hudson.remoting.UserResponse.retrieve(UserRequest.java:221)
at hudson.remoting.Channel.call(Channel.java:752)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.execute(RemoteGitImpl.java:145)
at sun.reflect.GeneratedMethodAccessor375.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.invoke(RemoteGitImpl.java:131)
at sun.proxy.$Proxy46.execute(Unknown Source)
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:733)
... 11 more
ERROR: Error fetching remote repo 'origin'
[xUnit] [INFO] - Starting to record.
[xUnit] [INFO] - Processing JUnit
[xUnit] [INFO] - [JUnit] - No test report file(s) were found with the pattern 
'xunit.xml' relative to 
' for the 
testing framework 'JUnit'.  Did you enter a pattern relative to the correct 
directory?  Did you generate the result report(s) for 'JUnit'?
[xUnit] [ERROR] - No test reports found for the metric 'JUnit' with the 
resolved pattern 'xunit.xml'. Configuration error?.
[xUnit] [INFO] - Failing BUILD.
[xUnit] [INFO] -

[GitHub] cloudstack pull request: Cloudstack:8647 LDAP Trust AD and Autoimp...

[koushik-das]

Github user koushik-das commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/755#discussion_r38515428
  
--- Diff: 
plugins/user-authenticators/ldap/src/org/apache/cloudstack/ldap/LdapAuthenticator.java
 ---
@@ -52,21 +58,71 @@ public LdapAuthenticator(final LdapManager ldapManager, 
final UserAccountDao use
 return new Pair(false, 
null);
 }
 
-final UserAccount user = _userAccountDao.getUserAccount(username, 
domainId);
+boolean result = false;
+ActionOnFailedAuthentication action = null;
 
-if (user == null) {
-s_logger.debug("Unable to find user with " + username + " in 
domain " + domainId);
-return new Pair(false, 
null);
-} else if (_ldapManager.isLdapEnabled()) {
-boolean result = _ldapManager.canAuthenticate(username, 
password);
-ActionOnFailedAuthentication action = null;
-if (result == false) {
+if (_ldapManager.isLdapEnabled()) {
+final UserAccount user = 
_userAccountDao.getUserAccount(username, domainId);
+LdapTrustMapVO ldapTrustMapVO = 
_ldapManager.getDomainLinkedToLdap(domainId);
+if(ldapTrustMapVO != null) {
+try {
+LdapUser ldapUser = _ldapManager.getUser(username, 
ldapTrustMapVO.getType().toString(), ldapTrustMapVO.getName());
+if(!ldapUser.isDisabled()) {
+result = 
_ldapManager.canAuthenticate(ldapUser.getPrincipal(), password);
+if(result) {
+if(user == null) {
+// import user to cloudstack
+createCloudStackUserAccount(ldapUser, 
domainId, ldapTrustMapVO.getAccountType());
--- End diff --

By authn I mean the call to LdapManager.canAuthenticate(). This will be 
successful in both cases but CS will report authn failure in once case due to 
account creation failure which is not intuitive. Account creation failure will 
be passed as authn failure.
But this will be a corner case scenario.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Instance reboot issue - CS 4.5.1 - Xen 6.5

[cs user]

Hi All,

We have seen this in 2 separate environments, both running the same
versions of Cloudstack and Xenserver. When we reboot an instance, we lose
access to it.

Looking at the iptables config on the xen host, we can see that the vif is
incremented for the bridged entries, but not updated for the rules.

For example, this is how the iptables look before a reboot:

[root@xen001 cloud]# iptables -L|grep 25075
i-2-25075-def  all  --  anywhere anywhere PHYSDEV
match --physdev-in vif108.0 --physdev-is-bridged
i-2-25075-def  all  --  anywhere anywhere PHYSDEV
match --physdev-out vif108.0 --physdev-is-bridged
Chain i-2-25075-VM (1 references)
Chain i-2-25075-VM-eg (1 references)
Chain i-2-25075-def (2 references)
RETURN udp  --  anywhere anywhere PHYSDEV match
--physdev-in vif108.0 --physdev-is-bridged match-set i-2-25075-VM src udp
dpt:domain
DROP   all  --  anywhere anywhere PHYSDEV match
--physdev-in vif108.0 --physdev-is-bridged ! match-set i-2-25075-VM src
DROP   all  --  anywhere anywhere PHYSDEV match
--physdev-out vif108.0 --physdev-is-bridged ! match-set i-2-25075-VM dst
i-2-25075-VM-eg  all  --  anywhere anywhere PHYSDEV
match --physdev-in vif108.0 --physdev-is-bridged match-set i-2-25075-VM src
i-2-25075-VM  all  --  anywhere anywhere PHYSDEV
match --physdev-out vif108.0 --physdev-is-bridged

After a reboot, we can see the following:

[root@xen001 cloud]# iptables -L|grep 25075
i-2-25075-def  all  --  anywhere anywhere PHYSDEV
match --physdev-in vif109.0 --physdev-is-bridged
i-2-25075-def  all  --  anywhere anywhere PHYSDEV
match --physdev-out vif109.0 --physdev-is-bridged
Chain i-2-25075-VM (1 references)
Chain i-2-25075-VM-eg (1 references)
Chain i-2-25075-def (2 references)
RETURN udp  --  anywhere anywhere PHYSDEV match
--physdev-in vif108.0 --physdev-is-bridged match-set i-2-25075-VM src udp
dpt:domain
DROP   all  --  anywhere anywhere PHYSDEV match
--physdev-in vif108.0 --physdev-is-bridged ! match-set i-2-25075-VM src
DROP   all  --  anywhere anywhere PHYSDEV match
--physdev-out vif108.0 --physdev-is-bridged ! match-set i-2-25075-VM dst
i-2-25075-VM-eg  all  --  anywhere anywhere PHYSDEV
match --physdev-in vif108.0 --physdev-is-bridged match-set i-2-25075-VM src
i-2-25075-VM  all  --  anywhere anywhere PHYSDEV
match --physdev-out vif108.0 --physdev-is-bridged

You can see that the bridged entries have been incremented to vif109, where
as the rules still reference vif108.

Stopping the instance appears to clear out the rules, and then everything
works fine again once the instance is started.

Is this a known issue? Is anyone able to replicate this?

Cheers!

Re: Facing BOOT issues (if DATA drives are attached) on VMs in CCP 4.5.0

[Rajani Karuturi]

whats the host and guest os?

~Rajani

On Wed, Sep 2, 2015 at 2:33 PM, anil lakineni <
anilkumar459.lakin...@gmail.com> wrote:

> Hi All,
>
> We are facing boot issues when VMs have DATA drives.
>
>
> *After VM was shut down we were unable to power on server unless we detach
> Data Drive.*
>
> We are using Citrix Cloud Portal 4.5.0 and XenServer 6.2
>
> *Note: *We have not facing this issue on some of the VM's which also have
> DATA drives but facing this kind of boot issue on only some VMs.
>
> If any one would have this kind of issue, please let us know the persistent
> solution to fix the issue.
> Thanks in advance.
>
> Regards,
> Anil.
>

[GitHub] cloudstack pull request: Quota

[bhaisaab]

Github user bhaisaab commented on the pull request:

https://github.com/apache/cloudstack/pull/768#issuecomment-137026221
  
The quota feature has three major packages;
- framework/quota
- plugin/database/quota
- usage/*Quota*Impls

Unit test coverage on framework/quota (was not sure how to write tests for 
VOs and DAOs, so does not include that):
![screenshot from 2015-09-02 16 10 
36](https://cloud.githubusercontent.com/assets/95203/9629077/a90af9f0-518d-11e5-9ef7-468f5a9a131d.png)

Unit test coverage on plugin/database/quota: (no explicit tests for API 
Response classes except for the response builder impl)
![screenshot from 2015-09-02 16 10 
44](https://cloud.githubusercontent.com/assets/95203/9629091/b786c360-518d-11e5-948e-3bd9b701d283.png)

Currently, I'm trying to refactor and write tests for two manager impls in 
usage package; coverage jfyi:
![screenshot from 2015-09-02 16 16 
00](https://cloud.githubusercontent.com/assets/95203/9629126/f7c7431e-518d-11e5-9e09-8328d453bc8f.png)



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cloudstack pull request: CLOUDSTACK-8688 - default policies for IN...

[wilderrodrigues]

Github user wilderrodrigues commented on the pull request:

https://github.com/apache/cloudstack/pull/765#issuecomment-137040420
  
Thanks for testing it, @karuturi, much appreciated!

I'm writing marvin tests for this PR and the other issue (CLOUDSTACK-8759). 
Once done, I will have a look at the problem you reported.

In order to keep things separate and move quicker with the PRs, could you 
please a separate issue with the details above?

Thanks in advance.

Cheers,
Wilder


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Facing BOOT issues (if DATA drives are attached) on VMs in CCP 4.5.0

[anil lakineni]

Hi Rajani,

Host is *XenServer 6.2*

Guest OS is *Windows 2008 R2 & Windows 2012 R2*

Regards,
Anil.

On Wed, Sep 2, 2015 at 3:42 PM, Rajani Karuturi  wrote:

> whats the host and guest os?
>
> ~Rajani
>
> On Wed, Sep 2, 2015 at 2:33 PM, anil lakineni <
> anilkumar459.lakin...@gmail.com> wrote:
>
> > Hi All,
> >
> > We are facing boot issues when VMs have DATA drives.
> >
> >
> > *After VM was shut down we were unable to power on server unless we
> detach
> > Data Drive.*
> >
> > We are using Citrix Cloud Portal 4.5.0 and XenServer 6.2
> >
> > *Note: *We have not facing this issue on some of the VM's which also have
> > DATA drives but facing this kind of boot issue on only some VMs.
> >
> > If any one would have this kind of issue, please let us know the
> persistent
> > solution to fix the issue.
> > Thanks in advance.
> >
> > Regards,
> > Anil.
> >
>

[GitHub] cloudstack pull request: Fixed issue in adding vm SG rules on vm r...

[csghuser]

Github user csghuser commented on the pull request:

https://github.com/apache/cloudstack/pull/479#issuecomment-137047840
  
Would it be possible to tell me which cloudstack release this fix is 
included in?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cloudstack pull request: CLOUDSTACK-8688 - default policies for IN...

[karuturi]

Github user karuturi commented on the pull request:

https://github.com/apache/cloudstack/pull/765#issuecomment-137048186
  
Ok. Here is the new issue 
https://issues.apache.org/jira/browse/CLOUDSTACK-8795

:+1: for this PR


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Instance reboot issue - CS 4.5.1 - Xen 6.5

[cs user]

Hi Folks,

Looks like this is fixed in https://github.com/apache/cloudstack/pull/479 ?

Which cloudstack release contains this fix?

Many thanks!

On Wed, Sep 2, 2015 at 11:16 AM, cs user  wrote:

> Forwarding to users channel in case anyone else has seen this...
>
>
>
> Hi All,
>
> We have seen this in 2 separate environments, both running the same
> versions of Cloudstack and Xenserver. When we reboot an instance, we lose
> access to it.
>
> Looking at the iptables config on the xen host, we can see that the vif is
> incremented for the bridged entries, but not updated for the rules.
>
> For example, this is how the iptables look before a reboot:
>
> [root@xen001 cloud]# iptables -L|grep 25075
> i-2-25075-def  all  --  anywhere anywhere PHYSDEV
> match --physdev-in vif108.0 --physdev-is-bridged
> i-2-25075-def  all  --  anywhere anywhere PHYSDEV
> match --physdev-out vif108.0 --physdev-is-bridged
> Chain i-2-25075-VM (1 references)
> Chain i-2-25075-VM-eg (1 references)
> Chain i-2-25075-def (2 references)
> RETURN udp  --  anywhere anywhere PHYSDEV
> match --physdev-in vif108.0 --physdev-is-bridged match-set i-2-25075-VM src
> udp dpt:domain
> DROP   all  --  anywhere anywhere PHYSDEV
> match --physdev-in vif108.0 --physdev-is-bridged ! match-set i-2-25075-VM
> src
> DROP   all  --  anywhere anywhere PHYSDEV
> match --physdev-out vif108.0 --physdev-is-bridged ! match-set i-2-25075-VM
> dst
> i-2-25075-VM-eg  all  --  anywhere anywhere
> PHYSDEV match --physdev-in vif108.0 --physdev-is-bridged match-set
> i-2-25075-VM src
> i-2-25075-VM  all  --  anywhere anywhere PHYSDEV
> match --physdev-out vif108.0 --physdev-is-bridged
>
> After a reboot, we can see the following:
>
> [root@xen001 cloud]# iptables -L|grep 25075
> i-2-25075-def  all  --  anywhere anywhere PHYSDEV
> match --physdev-in vif109.0 --physdev-is-bridged
> i-2-25075-def  all  --  anywhere anywhere PHYSDEV
> match --physdev-out vif109.0 --physdev-is-bridged
> Chain i-2-25075-VM (1 references)
> Chain i-2-25075-VM-eg (1 references)
> Chain i-2-25075-def (2 references)
> RETURN udp  --  anywhere anywhere PHYSDEV
> match --physdev-in vif108.0 --physdev-is-bridged match-set i-2-25075-VM src
> udp dpt:domain
> DROP   all  --  anywhere anywhere PHYSDEV
> match --physdev-in vif108.0 --physdev-is-bridged ! match-set i-2-25075-VM
> src
> DROP   all  --  anywhere anywhere PHYSDEV
> match --physdev-out vif108.0 --physdev-is-bridged ! match-set i-2-25075-VM
> dst
> i-2-25075-VM-eg  all  --  anywhere anywhere
> PHYSDEV match --physdev-in vif108.0 --physdev-is-bridged match-set
> i-2-25075-VM src
> i-2-25075-VM  all  --  anywhere anywhere PHYSDEV
> match --physdev-out vif108.0 --physdev-is-bridged
>
> You can see that the bridged entries have been incremented to vif109,
> where as the rules still reference vif108.
>
> Stopping the instance appears to clear out the rules, and then everything
> works fine again once the instance is started.
>
> Is this a known issue? Is anyone able to replicate this?
>
> Cheers!
>
>

[GitHub] cloudstack pull request: CLOUDSTACK-8678: Reserve RAM for KVM host...

[kmccormick]

Github user kmccormick commented on the pull request:

https://github.com/apache/cloudstack/pull/766#issuecomment-137155599
  
Regarding the upgrade scenario, I believe that this would not affect any 
running VMs. Can anyone confirm? Besides just running VMs, it is still a 
potential problem for an installation that is already near capacity, as the 
upgrade would remove a little bit of capacity. For both issues, I think a 
mention in the release notes would be sufficient. To keep the old behavior, 
admins just need to add host.reserved.ram.mb=0 to their agent.properties file.

CPU I don't think is an issue, as memory is typically the limiting factor 
in virtualization. If the CPU gets overly taxed, things slow down, where if all 
the memory gets used up, VMs or other processes get killed.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Facing BOOT issues (if DATA drives are attached) on VMs in CCP 4.5.0

[anil lakineni]

Dave,

Thanks for the replay and suggestion.

I believe in the CS when we deploy a fresh VM from Template or ISO a drive
is created which is ROOT drive (C drive) and it will acts as primary drive
(surely an entry will be created in Cloud DataBase tables to maintain this
record) for the VM until the END of VM life cycle, right? So we can say
ROOT drive is always a first boot order drive in the BIOS.
And later on added/attached drives will get numbers like 2,3 and so on..We
can see VM's drive numbers like 0,1,2,3 (Here *0* is primary drive which is
ROOT/C drive) and so on in XenCenter.
We were not facing this issue when rebooted VM from CloudPortal UI and only
facing issue when VM was shut down & thereafter next boot.

Please recommend me any suggestions on this issue.

Regards,
Anil.

On Wed, Sep 2, 2015 at 7:28 PM, Dave Dunaway  wrote:

> Check the boot order in the BIOS and make sure the VM is not trying to boot
> off the DATA disk. This is maybe why you don't see this issue when there is
> only one disk attached.
>
> hth.
>
> dave.
>
> On Wed, Sep 2, 2015 at 7:38 AM, anil lakineni <
> anilkumar459.lakin...@gmail.com> wrote:
>
> > Hi Rajani,
> >
> > Host is *XenServer 6.2*
> >
> > Guest OS is *Windows 2008 R2 & Windows 2012 R2*
> >
> > Regards,
> > Anil.
> >
> > On Wed, Sep 2, 2015 at 3:42 PM, Rajani Karuturi 
> wrote:
> >
> > > whats the host and guest os?
> > >
> > > ~Rajani
> > >
> > > On Wed, Sep 2, 2015 at 2:33 PM, anil lakineni <
> > > anilkumar459.lakin...@gmail.com> wrote:
> > >
> > > > Hi All,
> > > >
> > > > We are facing boot issues when VMs have DATA drives.
> > > >
> > > >
> > > > *After VM was shut down we were unable to power on server unless we
> > > detach
> > > > Data Drive.*
> > > >
> > > > We are using Citrix Cloud Portal 4.5.0 and XenServer 6.2
> > > >
> > > > *Note: *We have not facing this issue on some of the VM's which also
> > have
> > > > DATA drives but facing this kind of boot issue on only some VMs.
> > > >
> > > > If any one would have this kind of issue, please let us know the
> > > persistent
> > > > solution to fix the issue.
> > > > Thanks in advance.
> > > >
> > > > Regards,
> > > > Anil.
> > > >
> > >
> >
>

Re: Facing BOOT issues (if DATA drives are attached) on VMs in CCP 4.5.0

[Mike Tutkowski]

Do you have any management server log file you can share?

On Wed, Sep 2, 2015 at 10:45 AM, anil lakineni <
anilkumar459.lakin...@gmail.com> wrote:

> Dave,
>
> Thanks for the replay and suggestion.
>
> I believe in the CS when we deploy a fresh VM from Template or ISO a drive
> is created which is ROOT drive (C drive) and it will acts as primary drive
> (surely an entry will be created in Cloud DataBase tables to maintain this
> record) for the VM until the END of VM life cycle, right? So we can say
> ROOT drive is always a first boot order drive in the BIOS.
> And later on added/attached drives will get numbers like 2,3 and so on..We
> can see VM's drive numbers like 0,1,2,3 (Here *0* is primary drive which is
> ROOT/C drive) and so on in XenCenter.
> We were not facing this issue when rebooted VM from CloudPortal UI and only
> facing issue when VM was shut down & thereafter next boot.
>
> Please recommend me any suggestions on this issue.
>
> Regards,
> Anil.
>
> On Wed, Sep 2, 2015 at 7:28 PM, Dave Dunaway 
> wrote:
>
> > Check the boot order in the BIOS and make sure the VM is not trying to
> boot
> > off the DATA disk. This is maybe why you don't see this issue when there
> is
> > only one disk attached.
> >
> > hth.
> >
> > dave.
> >
> > On Wed, Sep 2, 2015 at 7:38 AM, anil lakineni <
> > anilkumar459.lakin...@gmail.com> wrote:
> >
> > > Hi Rajani,
> > >
> > > Host is *XenServer 6.2*
> > >
> > > Guest OS is *Windows 2008 R2 & Windows 2012 R2*
> > >
> > > Regards,
> > > Anil.
> > >
> > > On Wed, Sep 2, 2015 at 3:42 PM, Rajani Karuturi 
> > wrote:
> > >
> > > > whats the host and guest os?
> > > >
> > > > ~Rajani
> > > >
> > > > On Wed, Sep 2, 2015 at 2:33 PM, anil lakineni <
> > > > anilkumar459.lakin...@gmail.com> wrote:
> > > >
> > > > > Hi All,
> > > > >
> > > > > We are facing boot issues when VMs have DATA drives.
> > > > >
> > > > >
> > > > > *After VM was shut down we were unable to power on server unless we
> > > > detach
> > > > > Data Drive.*
> > > > >
> > > > > We are using Citrix Cloud Portal 4.5.0 and XenServer 6.2
> > > > >
> > > > > *Note: *We have not facing this issue on some of the VM's which
> also
> > > have
> > > > > DATA drives but facing this kind of boot issue on only some VMs.
> > > > >
> > > > > If any one would have this kind of issue, please let us know the
> > > > persistent
> > > > > solution to fix the issue.
> > > > > Thanks in advance.
> > > > >
> > > > > Regards,
> > > > > Anil.
> > > > >
> > > >
> > >
> >
>



-- 
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkow...@solidfire.com
o: 303.746.7302
Advancing the way the world uses the cloud
*™*

[GitHub] cloudstack pull request: CLOUDSTACK-8678: Reserve RAM for KVM host...

[wido]

Github user wido commented on the pull request:

https://github.com/apache/cloudstack/pull/766#issuecomment-137243367
  
@kmccormick Agreed. A release note would be enough since running VMs will 
not be affected.

CPU is a different problem indeed. Stuff becomes slow, but going Out of 
Memory is a bigger problem.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cloudstack pull request: CLOUDSTACK-8727: API call listVirtualMach...

[DaanHoogland]

Github user DaanHoogland commented on the pull request:

https://github.com/apache/cloudstack/pull/685#issuecomment-137254065
  
so now we are back to, "I would like to see two unit tests for 
checkForKeyByPublicKey. The succes and the failure cases. I am not sure if this 
check shows a very good pattern but that is out of scope for this PR. Other 
then unit tests missing, LGTM." I won't stop stop this with a :-1: but I think 
it can be augmented with more tests. 


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Facing BOOT issues (if DATA drives are attached) on VMs in CCP 4.5.0

[Dave Dunaway]

Check the boot order in the BIOS and make sure the VM is not trying to boot
off the DATA disk. This is maybe why you don't see this issue when there is
only one disk attached.

hth.

dave.

On Wed, Sep 2, 2015 at 7:38 AM, anil lakineni <
anilkumar459.lakin...@gmail.com> wrote:

> Hi Rajani,
>
> Host is *XenServer 6.2*
>
> Guest OS is *Windows 2008 R2 & Windows 2012 R2*
>
> Regards,
> Anil.
>
> On Wed, Sep 2, 2015 at 3:42 PM, Rajani Karuturi  wrote:
>
> > whats the host and guest os?
> >
> > ~Rajani
> >
> > On Wed, Sep 2, 2015 at 2:33 PM, anil lakineni <
> > anilkumar459.lakin...@gmail.com> wrote:
> >
> > > Hi All,
> > >
> > > We are facing boot issues when VMs have DATA drives.
> > >
> > >
> > > *After VM was shut down we were unable to power on server unless we
> > detach
> > > Data Drive.*
> > >
> > > We are using Citrix Cloud Portal 4.5.0 and XenServer 6.2
> > >
> > > *Note: *We have not facing this issue on some of the VM's which also
> have
> > > DATA drives but facing this kind of boot issue on only some VMs.
> > >
> > > If any one would have this kind of issue, please let us know the
> > persistent
> > > solution to fix the issue.
> > > Thanks in advance.
> > >
> > > Regards,
> > > Anil.
> > >
> >
>

RE: Facing BOOT issues (if DATA drives are attached) on VMs in CCP 4.5.0

[Patrick Chevalley]

Have you done any previous manipulation (e.g. storage migration, detach/attach, 
etc.)
Do you have more than 1 primary storage?
What is the state of the impacted volume(s) in the DB?
As already asked, look at the mgt logs for more details, or send the error.

-Original Message-
From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com] 
Sent: mercredi 2 septembre 2015 20:32
To: dev@cloudstack.apache.org
Cc: us...@cloudstack.apache.org
Subject: Re: Facing BOOT issues (if DATA drives are attached) on VMs in CCP 
4.5.0

Do you have any management server log file you can share?

On Wed, Sep 2, 2015 at 10:45 AM, anil lakineni < 
anilkumar459.lakin...@gmail.com> wrote:

> Dave,
>
> Thanks for the replay and suggestion.
>
> I believe in the CS when we deploy a fresh VM from Template or ISO a 
> drive is created which is ROOT drive (C drive) and it will acts as 
> primary drive (surely an entry will be created in Cloud DataBase 
> tables to maintain this
> record) for the VM until the END of VM life cycle, right? So we can 
> say ROOT drive is always a first boot order drive in the BIOS.
> And later on added/attached drives will get numbers like 2,3 and so 
> on..We can see VM's drive numbers like 0,1,2,3 (Here *0* is primary 
> drive which is ROOT/C drive) and so on in XenCenter.
> We were not facing this issue when rebooted VM from CloudPortal UI and 
> only facing issue when VM was shut down & thereafter next boot.
>
> Please recommend me any suggestions on this issue.
>
> Regards,
> Anil.
>
> On Wed, Sep 2, 2015 at 7:28 PM, Dave Dunaway 
> wrote:
>
> > Check the boot order in the BIOS and make sure the VM is not trying 
> > to
> boot
> > off the DATA disk. This is maybe why you don't see this issue when 
> > there
> is
> > only one disk attached.
> >
> > hth.
> >
> > dave.
> >
> > On Wed, Sep 2, 2015 at 7:38 AM, anil lakineni < 
> > anilkumar459.lakin...@gmail.com> wrote:
> >
> > > Hi Rajani,
> > >
> > > Host is *XenServer 6.2*
> > >
> > > Guest OS is *Windows 2008 R2 & Windows 2012 R2*
> > >
> > > Regards,
> > > Anil.
> > >
> > > On Wed, Sep 2, 2015 at 3:42 PM, Rajani Karuturi 
> > > 
> > wrote:
> > >
> > > > whats the host and guest os?
> > > >
> > > > ~Rajani
> > > >
> > > > On Wed, Sep 2, 2015 at 2:33 PM, anil lakineni < 
> > > > anilkumar459.lakin...@gmail.com> wrote:
> > > >
> > > > > Hi All,
> > > > >
> > > > > We are facing boot issues when VMs have DATA drives.
> > > > >
> > > > >
> > > > > *After VM was shut down we were unable to power on server 
> > > > > unless we
> > > > detach
> > > > > Data Drive.*
> > > > >
> > > > > We are using Citrix Cloud Portal 4.5.0 and XenServer 6.2
> > > > >
> > > > > *Note: *We have not facing this issue on some of the VM's 
> > > > > which
> also
> > > have
> > > > > DATA drives but facing this kind of boot issue on only some VMs.
> > > > >
> > > > > If any one would have this kind of issue, please let us know 
> > > > > the
> > > > persistent
> > > > > solution to fix the issue.
> > > > > Thanks in advance.
> > > > >
> > > > > Regards,
> > > > > Anil.
> > > > >
> > > >
> > >
> >
>



--
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkow...@solidfire.com
o: 303.746.7302
Advancing the way the world uses the cloud
*™*

Re: Facing BOOT issues (if DATA drives are attached) on VMs in CCP 4.5.0

[giljae o]

Hi,

How many are DATA disk attached to the VM?
If DATA disk is more than, try boot the VM with only 2 data disks.

James.

On Thursday, September 3, 2015, Patrick Chevalley 
wrote:

> Have you done any previous manipulation (e.g. storage migration,
> detach/attach, etc.)
> Do you have more than 1 primary storage?
> What is the state of the impacted volume(s) in the DB?
> As already asked, look at the mgt logs for more details, or send the error.
>
> -Original Message-
> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com ]
> Sent: mercredi 2 septembre 2015 20:32
> To: dev@cloudstack.apache.org 
> Cc: us...@cloudstack.apache.org 
> Subject: Re: Facing BOOT issues (if DATA drives are attached) on VMs in
> CCP 4.5.0
>
> Do you have any management server log file you can share?
>
> On Wed, Sep 2, 2015 at 10:45 AM, anil lakineni <
> anilkumar459.lakin...@gmail.com > wrote:
>
> > Dave,
> >
> > Thanks for the replay and suggestion.
> >
> > I believe in the CS when we deploy a fresh VM from Template or ISO a
> > drive is created which is ROOT drive (C drive) and it will acts as
> > primary drive (surely an entry will be created in Cloud DataBase
> > tables to maintain this
> > record) for the VM until the END of VM life cycle, right? So we can
> > say ROOT drive is always a first boot order drive in the BIOS.
> > And later on added/attached drives will get numbers like 2,3 and so
> > on..We can see VM's drive numbers like 0,1,2,3 (Here *0* is primary
> > drive which is ROOT/C drive) and so on in XenCenter.
> > We were not facing this issue when rebooted VM from CloudPortal UI and
> > only facing issue when VM was shut down & thereafter next boot.
> >
> > Please recommend me any suggestions on this issue.
> >
> > Regards,
> > Anil.
> >
> > On Wed, Sep 2, 2015 at 7:28 PM, Dave Dunaway  >
> > wrote:
> >
> > > Check the boot order in the BIOS and make sure the VM is not trying
> > > to
> > boot
> > > off the DATA disk. This is maybe why you don't see this issue when
> > > there
> > is
> > > only one disk attached.
> > >
> > > hth.
> > >
> > > dave.
> > >
> > > On Wed, Sep 2, 2015 at 7:38 AM, anil lakineni <
> > > anilkumar459.lakin...@gmail.com > wrote:
> > >
> > > > Hi Rajani,
> > > >
> > > > Host is *XenServer 6.2*
> > > >
> > > > Guest OS is *Windows 2008 R2 & Windows 2012 R2*
> > > >
> > > > Regards,
> > > > Anil.
> > > >
> > > > On Wed, Sep 2, 2015 at 3:42 PM, Rajani Karuturi
> > > > >
> > > wrote:
> > > >
> > > > > whats the host and guest os?
> > > > >
> > > > > ~Rajani
> > > > >
> > > > > On Wed, Sep 2, 2015 at 2:33 PM, anil lakineni <
> > > > > anilkumar459.lakin...@gmail.com > wrote:
> > > > >
> > > > > > Hi All,
> > > > > >
> > > > > > We are facing boot issues when VMs have DATA drives.
> > > > > >
> > > > > >
> > > > > > *After VM was shut down we were unable to power on server
> > > > > > unless we
> > > > > detach
> > > > > > Data Drive.*
> > > > > >
> > > > > > We are using Citrix Cloud Portal 4.5.0 and XenServer 6.2
> > > > > >
> > > > > > *Note: *We have not facing this issue on some of the VM's
> > > > > > which
> > also
> > > > have
> > > > > > DATA drives but facing this kind of boot issue on only some VMs.
> > > > > >
> > > > > > If any one would have this kind of issue, please let us know
> > > > > > the
> > > > > persistent
> > > > > > solution to fix the issue.
> > > > > > Thanks in advance.
> > > > > >
> > > > > > Regards,
> > > > > > Anil.
> > > > > >
> > > > >
> > > >
> > >
> >
>
>
>
> --
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkow...@solidfire.com 
> o: 303.746.7302
> Advancing the way the world uses the cloud
> *™*
>

[GitHub] cloudstack pull request: Cloudstack:8647 LDAP Trust AD and Autoimp...

[karuturi]

Github user karuturi commented on the pull request:

https://github.com/apache/cloudstack/pull/755#issuecomment-137344109
  
@koushik-das I created two issue for the open items. I will track these 
later
https://issues.apache.org/jira/browse/CLOUDSTACK-8797
https://issues.apache.org/jira/browse/CLOUDSTACK-8796


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Instance reboot issue - CS 4.5.1 - Xen 6.5

[Rajani Karuturi]

its in 4.5.2 and will also be in 4.6.0

~Rajani

On Wed, Sep 2, 2015 at 5:33 PM, cs user  wrote:

> Hi Folks,
>
> Looks like this is fixed in https://github.com/apache/cloudstack/pull/479
> ?
>
> Which cloudstack release contains this fix?
>
> Many thanks!
>
> On Wed, Sep 2, 2015 at 11:16 AM, cs user  wrote:
>
> > Forwarding to users channel in case anyone else has seen this...
> >
> >
> >
> > Hi All,
> >
> > We have seen this in 2 separate environments, both running the same
> > versions of Cloudstack and Xenserver. When we reboot an instance, we lose
> > access to it.
> >
> > Looking at the iptables config on the xen host, we can see that the vif
> is
> > incremented for the bridged entries, but not updated for the rules.
> >
> > For example, this is how the iptables look before a reboot:
> >
> > [root@xen001 cloud]# iptables -L|grep 25075
> > i-2-25075-def  all  --  anywhere anywhere PHYSDEV
> > match --physdev-in vif108.0 --physdev-is-bridged
> > i-2-25075-def  all  --  anywhere anywhere PHYSDEV
> > match --physdev-out vif108.0 --physdev-is-bridged
> > Chain i-2-25075-VM (1 references)
> > Chain i-2-25075-VM-eg (1 references)
> > Chain i-2-25075-def (2 references)
> > RETURN udp  --  anywhere anywhere PHYSDEV
> > match --physdev-in vif108.0 --physdev-is-bridged match-set i-2-25075-VM
> src
> > udp dpt:domain
> > DROP   all  --  anywhere anywhere PHYSDEV
> > match --physdev-in vif108.0 --physdev-is-bridged ! match-set i-2-25075-VM
> > src
> > DROP   all  --  anywhere anywhere PHYSDEV
> > match --physdev-out vif108.0 --physdev-is-bridged ! match-set
> i-2-25075-VM
> > dst
> > i-2-25075-VM-eg  all  --  anywhere anywhere
> > PHYSDEV match --physdev-in vif108.0 --physdev-is-bridged match-set
> > i-2-25075-VM src
> > i-2-25075-VM  all  --  anywhere anywhere PHYSDEV
> > match --physdev-out vif108.0 --physdev-is-bridged
> >
> > After a reboot, we can see the following:
> >
> > [root@xen001 cloud]# iptables -L|grep 25075
> > i-2-25075-def  all  --  anywhere anywhere PHYSDEV
> > match --physdev-in vif109.0 --physdev-is-bridged
> > i-2-25075-def  all  --  anywhere anywhere PHYSDEV
> > match --physdev-out vif109.0 --physdev-is-bridged
> > Chain i-2-25075-VM (1 references)
> > Chain i-2-25075-VM-eg (1 references)
> > Chain i-2-25075-def (2 references)
> > RETURN udp  --  anywhere anywhere PHYSDEV
> > match --physdev-in vif108.0 --physdev-is-bridged match-set i-2-25075-VM
> src
> > udp dpt:domain
> > DROP   all  --  anywhere anywhere PHYSDEV
> > match --physdev-in vif108.0 --physdev-is-bridged ! match-set i-2-25075-VM
> > src
> > DROP   all  --  anywhere anywhere PHYSDEV
> > match --physdev-out vif108.0 --physdev-is-bridged ! match-set
> i-2-25075-VM
> > dst
> > i-2-25075-VM-eg  all  --  anywhere anywhere
> > PHYSDEV match --physdev-in vif108.0 --physdev-is-bridged match-set
> > i-2-25075-VM src
> > i-2-25075-VM  all  --  anywhere anywhere PHYSDEV
> > match --physdev-out vif108.0 --physdev-is-bridged
> >
> > You can see that the bridged entries have been incremented to vif109,
> > where as the rules still reference vif108.
> >
> > Stopping the instance appears to clear out the rules, and then everything
> > works fine again once the instance is started.
> >
> > Is this a known issue? Is anyone able to replicate this?
> >
> > Cheers!
> >
> >
>