Paid Learning - How to submit a VMware-based course to production

Steps

1. Prepare each VM for start-of-lab. The steps will depend on what your lab requires. In general, make sure that all bookmark, applications, and files are available to your students, and that their locations/names/titles match what you have referenced in the lab guide.
2. Check OS entitlements: If Windows activation or RHEL subscription has expired, open a Techzone support ticket to have activation/subscription re-applied. Do this before submitting your final VMs.
3. Update OS patches - Windows Update for Windows systems or dnf update for RHEL (run as root).
4. Delete any unneeded files from your VMs; make sure there is no personal or IBM internal content on any of the VMs.
5. Check log or error/dump files and delete/cull them.
6. Check your browser history to make sure no IBM internal URLs are in your history.
7. Networking: If your environment is NOT clonable OCP, make sure that you are not using the gateway IP as your DNS server. For production paid learning environments, if you are not using clonable OCP, and you are not providing your own DNS server on one of your VMs, you should be using the IBM Cloud DNS servers:
       10.0.80.11
       10.0.80.12
   If you are using the default standard network settings provided with your development environment, and did not hard-code the DNS settings in your VMs, this setting will automatically default to the IBM Cloud DNS servers in the paid learning production environment.
8. Check your network settings and note their values; you will need to provide this to Techzone when you submit your final templates. If you are relying on static IPs, record the static IP for each VM that uses static. If you are using the standard settings provided with your development environment (gateway of 10.100.1.1, with DHCP) or you are using the clonable OCP environment, you don't need to provide the specific settings. On submission, you can just specify the "Standard" network configuration. 
9. Power your VMs down through the OS - you can either issue shutdown/powerdown commands from the OS, or use vCenter and select Power->Shutdown Guest OS. For clonable OCP-based environments see the Additional Information section below for preparing your cluster for final templates and powering down the cluster properly.
10. After all VMs have powered down, create a snapshot of each VM.
11. Once you have snapshots of your current powered-off state, power the VMs back on. Note the order that they are powered up in; you will need to provide this to Techzone when you submit your final templates. (You don't need to provide power-up order for clonable OCP environments.). If power-up order is not important, you can note that upon submission.
12. Verify that your environment powered back properly, and that any services/products started correctly. It is STRONGLY encouraged that you or a teammate actually complete the lab instructions to validate correct configuration, and also correct lab guide instructions. If you find any issues, revert your environment back to the "final candidate" snapshot, power your environment back up, fix any issues, and repeat steps 9-12 again. Don't forget to create a new set of snapshots, if your first snapshots are found to be incorrect.
13. Once your final-candidate environment has passed validation, revert back to your (good) final-candidate snapshots. Now you can prepare your VMs for final submission.

1. Make sure all required VMs are in the submission folder, and extra VMs are not in that folder. IMPORTANT: Do not include the Template-Builder router or (for clonable OCP) the (RHEL Guacamole) bastion VM in the final submission folder. They are not part of the final course template list and are for development only.
2. Name the submission folder CCCCCC_VV_DATE where 
   • CCCCCC =  paid learning course code
   • VV = version number (01, 02 etc. If this is the initial submission of this course, the version is 01)
   • DATE in MM-DD-YYYY format
     Example: TZ999G_03_06-11-2025
3. Make sure that all of your VMs in the folder are named correctly. Each VM name must consist of an optional prefix with a separator character, and VM "short" name. The short name will be included in cloned VMs for students. This is a name that you would have referenced in your lab guide, such as "BASTION" or "STUDENT" or "DB2SERVER".  This short name is what you will use to specify any static IP addresses and/or power-up order to Techzone on submission. Note that all production template names will be upper-case, no matter what case the submitted short name is. No spaces or special characters or underscore (_) are allowed in VM short names (but underscores can be separators). The same separator character must be used for all VMs in the folder.  If you have no prefix in your VM names, the entire source VM name will be used as the short name. If you have both dashes and underscores in your VM names, let us know which one is the separator character.
          Example: 6849d82c414451156aa14775-compute3 will have a VM short name of COMPUTE3
          Example: TZ999G-Dev-db2server (when dash is separator) will have a short name of DB2SERVER (the string after the last dash in the name)
          Example: TZ999G_01_student will have a short name of STUDENT
          Example: TZ999_Dev_db2-server (when underscore is separator) will have a short name of DB2-SERVER
          Example: instanaserver will have a short name of INSTANASERVER     
4. For at least one of the VMs, edit the Notes section. Enter relevant data, such as product versions installed, passwords. If this is an update to existing templates, add a short note of what was updated.
5. For clonable-OCP environments: Because the Template-Builder environment already included a VM named "bastion", the OCP bastion has a VM short name of "bastion-ocp". After making sure that the Template-Builder bastion and router VMs are not in the final folder, rename the bastion-ocp VM to just bastion.