[
https://issues.apache.org/jira/browse/CLOUDSTACK-8608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14611769#comment-14611769
]
ASF GitHub Bot commented on CLOUDSTACK-8608:
--------------------------------------------
GitHub user likitha opened a pull request:
https://github.com/apache/cloudstack/pull/555
CLOUDSTACK-8608. System VM's failed to start due to permissions issue.
…instance.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/likitha/cloudstack CLOUDSTACK-8608
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/cloudstack/pull/555.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 #555
----
commit 7b87e8a4184c046917f71627db9a20871ae981b4
Author: Likitha Shetty <[email protected]>
Date: 2015-04-20T12:59:55Z
CLOUDSTACK-8608. System VM's 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: 4.6.0
>
>
> 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)
