You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cloudstack.apache.org by "ASF GitHub Bot (JIRA)" <ji...@apache.org> on 2016/12/29 09:18:58 UTC
[jira] [Commented] (CLOUDSTACK-8608) Fix unpleasant admin
experience with VMware fresh installs/upgrades - System VM's failed to
start due to permissions issue
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15784925#comment-15784925 ]
ASF GitHub Bot commented on CLOUDSTACK-8608:
--------------------------------------------
GitHub user sureshanaparti opened a pull request:
https://github.com/apache/cloudstack/pull/1875
CLOUDSTACK-8608: [VMware] System VMs failed to start due to permissions issue. Provide permissions to template folder when mounted on management server.
[VMware] System VMs failed to start due to permissions issue. Provide permissions to template folder when mounted on management server.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/Accelerite/cloudstack CLOUDSTACK-8608
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/cloudstack/pull/1875.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #1875
----
commit c1c77a9d7cdc472962050c7eeea0ea51ddc16bda
Author: Suresh Kumar Anaparti <su...@accelerite.com>
Date: 2016-12-29T09:10:01Z
CLOUDSTACK-8608: [VMware] System VMs failed to start due to permissions issue. Provide permissions to template folder when mounted on management server.
----
> Fix unpleasant admin experience with VMware fresh installs/upgrades - System VM's failed to start due to permissions issue
> --------------------------------------------------------------------------------------------------------------------------
>
> Key: CLOUDSTACK-8608
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8608
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the default.)
> Reporter: Likitha Shetty
> Assignee: Likitha Shetty
> Fix For: Future
>
>
> VMware uses a folder in machine where management server is running to mount secondary storage. This is a bootstrap phase to start system vm, because unlike KVM, Xenserver, management server cannot directly access VMWare ESXI host to download systemvm template from secondary storage to primary storage. The secondary storage is usually managed by SSVM that uses root account to download templates. However, management server is using account 'cloud' to manipulate templates after secondary storage is mounted. After admin registers new systemvm template in CS as a normal upgrade procedure, the old SSVM will download the template using account root, but management server will create new SSVM from the new template using account 'cloud'. Then a permission denied error will raise.
> Prior to 4.4, CS used to handle this by running 'chmod -R' to the folder to which secondary storage is mounted every time management server mounts secondary storage. Unfortunately, this method is slow because we are trying to give permissions to the entire folder. So in 4.4, we stopped automatically providing the permissions and asked admin to manually run 'chmod -R' to the folder 'templates' on secondary storage, after registering new systemvm template.
> We can avoid this manual admin step by only providing permissions for the /templates folder instead of the entire folder. This way we will avoid the snapshots folder which could be very large in upgrade setups.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)