Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Docs: reinforce warning against unshared storage #1188

Closed
stuclem opened this issue Nov 30, 2017 · 3 comments
Closed

Docs: reinforce warning against unshared storage #1188

stuclem opened this issue Nov 30, 2017 · 3 comments
Assignees
Labels
area/pub/vsphere Published documentation for vSphere administrators area/pub Published documentation for end-users product/engine Related to the vSphere Integrated Containers Engine

Comments

@stuclem
Copy link
Contributor

stuclem commented Nov 30, 2017

Per vmware/vic-ui#72 (comment) we need to reinforce the warning in the docs about not using storage that is not available to all hosts in the cluster

@stuclem stuclem added product/engine Related to the vSphere Integrated Containers Engine area/pub Published documentation for end-users priority/high area/pub/vsphere Published documentation for vSphere administrators labels Nov 30, 2017
@stuclem stuclem self-assigned this Nov 30, 2017
@stuclem
Copy link
Contributor Author

stuclem commented Dec 5, 2017

Added the following to the docs:

https://github.com/stuclem/vic-product/blob/vchui/docs/user_doc/vic_vsphere_admin/vch_storage.md

Storage Requirements and Limitations

The storage that you select for use as image and volume stores for VCHs must meet the following requirements.

  • vSphere Integrated Containers Engine fully supports VMware vSAN datastores.

  • vSphere Integrated Containers Engine supports all alphanumeric characters, hyphens, and underscores in datastore paths and datastore names, but no other special characters.

  • Datastores that you specify as image and volume stores should ideally be accessible to all of the hosts in a cluster. Specifying storage that is not accessible to all of the hosts in a cluster is possible, but might result in all of your container VMs and container volumes being placed on the same host.

  • If you specify different datastores in the different datastore options, and if no single host in a cluster can access all of the datastores, VCH deployment fails with an error.

    No single host can access all of the requested datastores.
    Installation cannot continue.

  • If you specify different datastores in the different datastore options, and if only one host in a cluster can access all of them, VCH deployment succeeds with a warning.

    Only one host can access all of the image/container/volume datastores. This may be a point of contention/performance degradation and HA/DRS may not work as intended.

  • VCHs do not support datastore name changes. If a datastore changes name after you have deployed a VCH that uses that datastore, that VCH will no longer function.

@zjs does this cover it?

@stuclem
Copy link
Contributor Author

stuclem commented Dec 5, 2017

Added the following in the topic on the image store:


If you are deploying the VCH to a vCenter Server cluster, the datastore that you designate as the image store must be shared by at least two, but preferably all, ESXi hosts in the cluster. Using non-shared datastores is possible, but limits the use of vSphere features such as vSphere vMotion® and VMware vSphere Distributed Resource Scheduler™ (DRS). Using non-shared datastores might lead to situations in which all container VMs and image files are stored on a single host.


@zjs is this OK?

@stuclem
Copy link
Contributor Author

stuclem commented Jan 18, 2018

Reviewed by @matthewavery and @anchal-agrawal in #1259.

@stuclem stuclem closed this as completed Jan 18, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/pub/vsphere Published documentation for vSphere administrators area/pub Published documentation for end-users product/engine Related to the vSphere Integrated Containers Engine
Projects
None yet
Development

No branches or pull requests

1 participant