Document how to configure the OS of a container VM

[stuclem]

Per comment by @corrieb in https://github.com/vmware/vic/issues/6279, we need to document how to configure certain elements of the container VM OS.

Comment from @corrieb reproduced here:

---

I suggest we add a section on configuring the cVM OS and add all of the common requirements - swap space, hostname etc. Some of these will have proper support and others may need some workarounds. We can update the doc as we improve support.

I can also predict that before long a customer will ask to be able to set custom values in the VMX of cVMs deployed. I heard that from customers 2 years ago.

---

[stuclem]

Full (evolving) list of container VM config operations is being tracked in Epic https://github.com/vmware/vic/issues/6418.

[stuclem]

I don't think that we have the info for this yet. Removing from 1.3.

[stuclem]

There is development work associated with this that has not yet been done, but there might be things that we need to document now.

@dbarkelew can you think of anything that we need to/can document immediately?

[dbarkelew]

There are a few workaround that have been used successfully.

• Build a new image that includes a script, or binary that sets the desired options at startup.
• When creating or running the container set the entrypoint as a scrip that waits until the needed options are set before continuing the container startup. Then to set the values use docker exec to set the options manually.

These KBs use some of these workarounds to do this. https://kb.vmware.com/s/article/2151794 https://ikb.vmware.com/s/article/56973 (Internal right now until publishing is approved.)

Having the workaround as part of the image is more desirable since it will be easily compatible with docker-compose and admiral. Might make sense for an addition to the tutorials? Could make generic instruction for doing this in an image build and has potential to be used for other customization of an image as well aside from kernel parameters.

1. Create new script for the entry point and will execute what is needed at start up and then kick off the original entry point of the image without losing any parameters that were passed to the container. Creating a "vic-entrypoint.sh" like this should work.

   # commands to set what is needed.
   ulimit -S -s 8192
   # (optional) custom binary if the situation calls for it
   /someCustomBinary
   exec /usr/local/bin/docker-entrypoint.sh "$@"

2. Add a copy and execute at the end of the dockerfile.

   #
   #
   # Copying entry point modifications
   COPY vic-entrypoint.sh /usr/local/bin/vic-entrypoint.sh
   #
   # If using a custom binary to set the kernel parameters. 
   # This is useful if the container runs as a user that does not have root permissions to directly change kernel parameters via the vic-entrypoint.sh script. 
   # If the container runs as root which most do, then using a binary is not needed.
   # In this example the group the user that runs in the container is 1000. Can be different per container.
   COPY someCustomBinary /someCustomBinary
   RUN chown 0:1000 /someCustomBinary &&\
   chmod 755 /someCustomBinary &&\
   chmod u+s /someCustomBinary &&\
   chown 1000:0 /usr/local/bin/vic-entrypoint.sh &&\
   chmod 755 /usr/local/bin/vic-entrypoint.sh
   #
   # Setting the new entry point
   ENTRYPOINT ["/usr/local/bin/vic-entrypoint.sh"]

3. Build the image and use normally. Example using the dch-photon here might be useful.

[stuclem]

Per offline chat with @dbarkelew, we aren't really sure whether this kind of info should go into the official docs. @hickeng what do you think?

Moving back to Not Ready.

[zjs]

I discussed this with @hickeng and we agree this seems useful for the official docs as we prefer not to hide this valuable information. This could be framed as how to workaround the current lack of capabilities (if such framing is useful). @stuclem, please work with @dbarkelew to gather instructions and ask @renmaosheng for QE resources to validate/review.

[stuclem]

OK, thanks @zjs

[stuclem]

@renmaosheng should we address this in 1.5.4?

[stuclem]

Not for 1.5.4.