As the differences related to (1) are already documented generically in our Tutorial, How-to guides, and Reference docs, here we record just those that follow from (2).
datastore The datastore in which to create VMs. If this is not specified, the process will abort unless there is only one datastore available.
disk-provisioning-type This dictates how template VM disks should be cloned when creating a new machine. Valid values:
- thin - Sparse provisioning, only written blocks will take up disk space on the datastore
- thick - The entire size of the virtual disk will be deducted from the datastore, but unwritten blocks will not be zeroed out. This adds 2 potential pitfalls. See comments in provider/vsphere/internal/vsphereclient/client.go regarding DiskProvisioningType.
- thickEagerZero (default) - The entire size of the virtual disk is deducted from the datastore, and unwritten blocks are zeroed out. Improves latency when committing to disk, as no extra step needs to be taken before writing data.
external-network An external network that VMs will be connected to. The resulting IP address for a VM will be used as its public address. An external network provides the interface to the internet for virtual machines connected to external organization vDC networks.
force-vm-hardware-version (integer) Adds a new model level flag that allows operators to set a newer compatibility version for the instances that get spawned by juju. E.g., juju bootstrap vsphere --config force-vm-hardware-version=17
primary-network The primary network that VMs will be connected to. If this is not specified, Juju will look for a network named VM Network.
auth-type: userpass. You will have to provide your username, password and, optionally, the vmfolder.
If your credential stops working: Credentials for the vSphere cloud have been reported to occasionally stop working over time. If this happens, try juju update-credential (passing as an argument the same credential) or juju add-credential (passing as an argument a new credential) + juju default-credential.
Recommended: Bootstrap with the following cloud-specific model-configuration keys: datastore and primary-network. See more below.
Pro tip: When creating a controller with vSphere, a cloud image is downloaded to the client and then uploaded to the ESX host. This depends on your network connection and can take a while. Using templates can speed up bootstrap and machine deployment.
If your topology has a cluster without a host, Juju will see this as an availability zone and may fail silently. To solve this, either make sure the host is within the cluster, or use a placement directive: juju bootstrap vsphere/<datacenter> <controllername> --to zone=<cluster|host>.
To speed up bootstrap and deploy, you can use VM templates, already created in your vSphere. Templates can be created by hand on your vSphere, or created from an existing VM.
Examples assume that the templates are in directory $DATA_STORE/templates.
It would be nice to explain the minimum required privileges need in vSphere to bootstrap/deploy a juju environment to a vSphere cloud. Based on this commit [1] we know at least System.Read is required on the Datacenter entity. Clearly you need more than just read.
We are running juju with vsphere and have some experience.
The latest release of juju came with alot of changes to improve the situation with vsphere but I agree that it’s unclear just exactly how to setup any cloud for a proper juju situation. Lxd might be the best documented cloud in my opinion.
We have experimented our way forward and are not super happy about that.
Erik,
When giving juju an admin account everything is fine, but in the spirit of security and least privileged access it would be good to know exactly what that least privilege is. We also have customers that have this requirement and would like to see this documentation.
I am not an expert in VMware, so I rely on some people at work to deal with these things which in our case also relates to Active directory I think.
But, the main issue for me at the moment is to be able to properly separate users views on provisioned vms etc. This is what seems to be partially solved/addressed/mitigated with later versions of juju.
The previous situation was that every user had a view of all vms for everyone since user access was enabled for the whole datacenter in vsphere.
To address some of these concerns, I hope to expand the post below into a full guide. It sounds like guide should be supplemented for guides for each cloud.
The description assumes that datacenters are the top level resources. However, we saw some cases where a datacenter was under a folder, for example in LP: #1884490.
It would be nice if the doc covers such a scenario and the usecase is validated. I’m talking about the case govc returns the following.
$ govc ls
/MyFolder/MyDC/vm
/MyFolder/MyDC/network
/MyFolder/MyDC/host
/MyFolder/MyDC/datastore
and Juju config syntax would look like the following:
regions:
dc0: {} # these empty maps
dc1: {} # are necessary
MyFolder/MyDC: {} # datacenter under a folder
What would the “primary-network” typically look like from a IP point of view? 172.X.X.X or would it be something else?
Will juju automatically create VM:s with 2 NICs connected to these networks (primary-network + external-network) if they are available?
[Update #1] Yes, I see from experimentation that juju seem to spawn nodes with a second NIC if I set "juju config external-network=NETWORK_NAME_2" and attaches that to the running VM:s. So, I guess that the assignment if their IP:s now needs a second DHCP server also running on that network?
I didn’t know there was such a tool “govc” is this a supported tool or what can you tell me about it? It looks very interesting to use in conjunction with juju for vsphere cloud.
20:27:43 DEBUG juju.environs.simplestreams simplestreams.go:491 skipping index "file:///home/ubuntu/simplestreams/images/streams/v1/index.json" because of missing information: "image-downloads" data not found
It seems that Juju is still searching for ‘image-url’ in order to download the data, when it should not do any downloads. In the end, the bootstrap works but because it falls back to download from the internet.
Juju does inject some things into the general templates when one is not specified. I’ve had the best experience copying a template created by juju to a folder which can be shared within the datastore.
Also double check the location specified in the $HOME/simplestreams/images/streams/v1/com.ubuntu.cloud-released-imagemetadata.json file. Each image has an id like "id": "juju-ci-root/templates/focal-test-template", that you should be able to find in the datastore. juju-ci-root is a directory in the datastore. I also use it as the vmfolder specified in my vsphere credentials.
A second thought is there is a conflict by specifying both --metadata-source $HOME/simplestreams --bootstrap-series=focal and --bootstrap-image="cloud-images/ubuntu-20.04-server-cloudimg-amd64.ova" at bootstrap. You’re giving juju seemingly 2 sources of truth. Please try again, leaving out the --bootstrap-image flag.
If your credential stops working: Credentials for the vSphere cloud have been reported to occasionally stop working over time. If this happens, try