Documentation: Provisioning Fedora CoreOS on VMware: Improvement Suggestions to GOVC Instructions

[fifofonix]

Summary

As part of test day activities I followed these instructions and had some observations principally regarding the use of govc for deploying to vSphere 6.7:

• https://fedoraproject.org/wiki/QA:Testcase_CoreOS_VMware
• https://docs.fedoraproject.org/en-US/fedora-coreos/provisioning-vmware/

I used an ad-hoc Fedora:35 container to deploy govc using the dnf based instructions in link #1.

Detail

Specifying vSphere Credentials

Consider using the GOVC_USERNAME etc environment variables instead of govc -u user:password@host.

In an environment where vSphere access is via Active Directory credentials may require to be expressed as AD\user or [email protected] format to successfully authenticate. Both of these require careful escaping if used in the govc session.login -u user:password@host format. However, even when I achieved apparent successful logins with escaping I experienced subsequent errors on simple govc commands, e.g:

[root@2c1032aa1ee9 /]# govc session.login -u user:password@host
[root@2c1032aa1ee9 /]# govc ls
govc: specify an ESX or vCenter URL

This issue was resolved by moving to the environment variables method.

Directly Deploying an OVA vs Deploying via Library Template

Consider whether the example should deploy directly from an OVA as opposed to via a Library Template. Yes, having a pre-loaded template in a library is probably a good thing to do if you're deploying lots of VMs but perhaps the hello-world example should keep it simpler. This would mean replacing the library-related lines (other instructions remain as-is):

govc  import.ova -name ${VM_NAME} ${FCOS_OVA}

In my case I found a couple of issues with the library approach which eventually led me to deploy directly:

• Creating library templates actually required additional privileges to my CICD tooling credentials.
• Even with escalated credentials I was unable to create the library resources due to likely site-specific vSphere configuration issues.

[dustymabe]

@lucab @fifofonix - did we ever figure out if there are docs updates we wanted to make as part of this?

[fifofonix]

@lucab, @dustymabe I think it is your team's call but if you do want to proceed I'd be more than happy to submit a pull request with suggested changes. I just didn't want to spend the time figuring out how to build/test the docs etc without your buy-in.

[Okeanos]

I recently noticed this issue and decided to provide a PR to address your findings (as nothing happened the past year to invalidate them in my opinion). Feel free to chime in.

[Okeanos]

@dustymabe with docs#526 having been merged I wonder whether this issue here can also be closed?

[dustymabe]

SGTM Will Close.

@fifofonix feel free to re-open if you disagree.