[
https://issues.apache.org/jira/browse/CLOUDSTACK-8608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15906748#comment-15906748
]
ASF GitHub Bot commented on CLOUDSTACK-8608:
--------------------------------------------
Github user sureshanaparti commented on a diff in the pull request:
https://github.com/apache/cloudstack/pull/1875#discussion_r105573382
--- Diff:
plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/manager/VmwareManagerImpl.java
---
@@ -707,6 +709,23 @@ private String setupMountPoint(String parent) {
return mountPoint;
}
+ @Override
+ public synchronized void setSystemVmTmpltPermission(String mountPoint)
{
+ if (!s_isSystemVmTmpltPermissionSet) {
+ s_logger.debug("Set permissions for " + mountPoint);
+ String result = null;
+ final String systemVmTmpltPermissions = "0777";
+ Script script = new Script(true, "chmod", _timeout, s_logger);
+ script.add("-R", systemVmTmpltPermissions, mountPoint);
--- End diff --
@SudharmaJain Moved to TemplateConstants.
> 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: Suresh Kumar Anaparti
> 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.15#6346)
