docs: document full VM import spec #684
Conversation
|
- Document the full VM import spec, i.e. all properties of the VirtualMachineImport CRD by giving appropriate examples. - Put examples for OpenStack and VMWare in tabs - Fix whitespaces and long lines Signed-off-by: Moritz Röhrich <[email protected]>
m-ildefons
force-pushed
the
wip/vm-import-addon-spec
branch
from
413161f to
f7c83fb
Compare
docs/advanced/addons/vmimport.md
Outdated
| This will trigger the controller to export the VM named "alpine-export-test" | ||
| from the folder "/vm-folder" on the VMWare source cluster to be exported, | ||
| processed and recreated into the harvester cluster |
There was a problem hiding this comment.
| This will trigger the controller to export the VM named "alpine-export-test" | |
| from the folder "/vm-folder" on the VMWare source cluster to be exported, | |
| processed and recreated into the harvester cluster | |
| This CRD prompts the controller to export the virtual machine named "alpine-export-test" from the folder `/vm-folder`, which is on the source VMWare cluster that is to be exported, processed, and recreated into the Harvester cluster. |
There was a problem hiding this comment.
This sentence is still awkward: This CRD prompts the controller to export the virtual machine .... to be exported, ...
I'll reformulate it so it doesn't have export in it twice.
docs/advanced/addons/vmimport.md
Outdated
| OpenStack allows users to have multiple instances with the same name. In such a | ||
| scenario, users are advised to use the Instance ID. The reconciliation logic | ||
| tries to perform a name-to-ID lookup when a name is used. | ||
| ::: |
There was a problem hiding this comment.
| :::note | |
| OpenStack allows users to have multiple instances with the same name. In such a | |
| scenario, users are advised to use the Instance ID. The reconciliation logic | |
| tries to perform a name-to-ID lookup when a name is used. | |
| ::: | |
| :::note | |
| OpenStack allows the creation of multiple instances with the same host name. In this scenario, you are advised to use the instance ID. The reconciliation logic attempts to perform a name-to-ID lookup whenever a name is used. | |
| ::: |
There was a problem hiding this comment.
Do you want to specify that the host name is what can be identical across instances? Asking because I found this doc topic and thought that we could be a bit more specific here. If I misunderstood, please dismiss this comment.
There was a problem hiding this comment.
This entire sentence is weird. The OpenStack docs you linked don't even mention an 'instance ID', but to me it sounds like the original sentence refers to the instance name, not the host name. The OpenStack docs are pretty ambiguous as well because they throw a 'server name' into the mix.
I think the comment from the code example gives a good hint to clear things up:
None of this refers to the host name, as that's a property that can change dynamically and will not necessarily be reflected in the OpenStack control plane.
'Name' refers to the 'instance name' from the OpenStack docs.
The 'instance ID' refers to the UUID, which isn't mentioned in the linked OpenStack docs. But I know that OpenStack uses a UUID to uniquely identify VMs on the command line.
@irishgordo Didn't you do some testing with OpenStack the other day? Can you help clear this up?
docs/advanced/addons/vmimport.md
Outdated
| see `VirtualMachineImages` created for each disk in the defined virtual machine. | ||
|
|
||
| The list of items in `networkMapping` will define how the source network | ||
| interfaces are mapped to the Harvester Networks. | ||
|
|
||
| If a match is not found, each unmatched network interface is attached to the | ||
| default `managementNetwork`. | ||
|
|
||
| Once the virtual machine has been imported successfully, the object will reflect | ||
| the status: |
There was a problem hiding this comment.
| This can take a while based on the size of the virtual machine, but users should | |
| see `VirtualMachineImages` created for each disk in the defined virtual machine. | |
| The list of items in `networkMapping` will define how the source network | |
| interfaces are mapped to the Harvester Networks. | |
| If a match is not found, each unmatched network interface is attached to the | |
| default `managementNetwork`. | |
| Once the virtual machine has been imported successfully, the object will reflect | |
| the status: | |
| This process can take a while depending on the virtual machine size, but you should see `VirtualMachineImages` created for each disk in the defined virtual machine. | |
| The entries listed under `networkMapping` determine how the source network interfaces are mapped to the Harvester networks. If no matches are found, each unmatched network interface is attached to the default `managementNetwork`. | |
| Once the virtual machine is imported successfully, the status of the object changes to `virtualMachineRunning`. | |
| Example: |
Signed-off-by: Moritz Röhrich <[email protected]>
Document the full VM import spec, i.e. all properties of the VirtualMachineImport CRD by giving appropriate examples.
Put examples for OpenStack and VMWare in tabs
Fix whitespaces and long lines