Mailing-List: contact issues-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Date: Mon, 20 Feb 2017 14:52:44 +0000 (UTC)
From: "ASF GitHub Bot (JIRA)" <jira@apache.org>
To: cloudstack-issues@incubator.apache.org
Message-ID: <JIRA.12842251.1435825530000.11053.1487602364066@Atlassian.JIRA>
In-Reply-To: <JIRA.12842251.1435825530000@Atlassian.JIRA>
References: <JIRA.12842251.1435825530000@Atlassian.JIRA> <JIRA.12842251.1435825530762@jira-lw-us.apache.org>
Subject: [jira] [Commented] (CLOUDSTACK-8608) Fix unpleasant admin
 experience with VMware fresh installs/upgrades - System VM's failed to
 start due to permissions issue
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
archived-at: Mon, 20 Feb 2017 14:52:56 -0000


    [ https://issues.apache.org/jira/browse/CLOUDSTACK-8608?page=3Dcom.atla=
ssian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=
=3D15874635#comment-15874635 ]=20

ASF GitHub Bot commented on CLOUDSTACK-8608:
--------------------------------------------

Github user blueorangutan commented on the issue:

    https://github.com/apache/cloudstack/pull/1875
 =20
    Packaging result: =E2=9C=94centos6 =E2=9C=94centos7 =E2=9C=94debian. JI=
D-511


> Fix unpleasant admin experience with VMware fresh installs/upgrades - Sys=
tem VM's failed to start due to permissions issue
> -------------------------------------------------------------------------=
-------------------------------------------------
>
>                 Key: CLOUDSTACK-8608
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-860=
8
>             Project: CloudStack
>          Issue Type: Bug
>      Security Level: Public(Anyone can view this level - this is the defa=
ult.)=20
>            Reporter: Likitha Shetty
>            Assignee: Likitha Shetty
>             Fix For: Future
>
>
> VMware uses a folder in machine where management server is running to mou=
nt secondary storage. This is a bootstrap phase to start system vm, because=
 unlike KVM, Xenserver, management server cannot directly access VMWare ESX=
I host to download systemvm template from secondary storage to primary stor=
age. The secondary storage is usually managed by SSVM that uses root accoun=
t to download templates. However, management server is using account 'cloud=
' to manipulate templates after secondary storage is mounted. After admin r=
egisters 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 pe=
rmission 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 s=
econdary storage. Unfortunately, this method is slow because we  are trying=
 to give permissions to the entire folder. So in 4.4, we stopped automatica=
lly providing the permissions and asked admin to manually run 'chmod -R' to=
 the folder 'templates' on secondary storage, after registering new systemv=
m 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)