Likitha Shetty created CLOUDSTACK-8608:
------------------------------------------
Summary: 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)
