cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <>
Subject [jira] [Commented] (CLOUDSTACK-8608) Fix unpleasant admin experience with VMware fresh installs/upgrades - System VM's failed to start due to permissions issue
Date Mon, 13 Mar 2017 00:02:04 GMT


ASF GitHub Bot commented on CLOUDSTACK-8608:

Github user sureshanaparti commented on a diff in the pull request:
    --- Diff: plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/manager/
    @@ -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:
>             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

View raw message