You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
- 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]>
By default, vm-import-controller leverages ephemeral storage, which is mounted from /var/lib/kubelet.
23
+
By default, vm-import-controller leverages ephemeral storage, which is mounted
24
+
from /var/lib/kubelet.
22
25
23
-
During the migration, a large VM's node could run out of space on this mount, resulting in subsequent scheduling failures.
26
+
During the migration, a large VM's node could run out of space on this mount,
27
+
resulting in subsequent scheduling failures.
24
28
25
-
To avoid this, users are advised to enable PVC-backed storage and customize the amount of storage needed. According to the best practice, the PVC size should be twice the size of the largest VM being migrated. This is essential as the PVC is used as scratch space to download the VM, and convert the disks into raw image files.
29
+
To avoid this, users are advised to enable PVC-backed storage and customize the
30
+
amount of storage needed. According to the best practice, the PVC size should be
31
+
twice the size of the largest VM being migrated. This is essential as the PVC is
32
+
used as scratch space to download the VM, and convert the disks into raw image
Currently, the following source providers are supported:
40
+
32
41
* VMWare
33
42
* OpenStack
34
43
35
44
## API
45
+
36
46
The vm-import-controller introduces two CRDs.
37
47
38
48
### Sources
49
+
39
50
Sources allow users to define valid source clusters.
40
51
41
52
For example:
42
53
54
+
<Tabs>
55
+
<TabItemvalue="vmware"label="VMWare"default>
43
56
```yaml
44
57
apiVersion: migration.harvesterhci.io/v1beta1
45
58
kind: VmwareSource
@@ -59,24 +72,27 @@ The secret contains the credentials for the vCenter endpoint:
59
72
```yaml
60
73
apiVersion: v1
61
74
kind: Secret
62
-
metadata:
75
+
metadata:
63
76
name: vsphere-credentials
64
77
namespace: default
65
78
stringData:
66
79
"username": "user"
67
80
"password": "password"
68
81
```
69
82
70
-
As part of the reconciliation process, the controller will log into vCenter and verify whether the `dc` specified in the source spec is valid.
83
+
As part of the reconciliation process, the controller will log into vCenter and
84
+
verify whether the `dc` specified in the source spec is valid.
71
85
72
-
Once this check is passed, the source is marked as ready and can be used for VM migrations.
86
+
Once this check is passed, the source is marked as ready and can be used for VM
87
+
migrations.
73
88
74
89
```shell
75
-
$ kubectl get vmwaresource.migration
90
+
$ kubectl get vmwaresource.migration
76
91
NAME STATUS
77
92
vcsim clusterReady
78
93
```
79
-
94
+
</TabItem>
95
+
<TabItem value="openstack" label="OpenStack">
80
96
For OpenStack-based source clusters, an example definition is as follows:
81
97
82
98
```yaml
@@ -98,7 +114,7 @@ The secret contains the credentials for the OpenStack endpoint:
98
114
```yaml
99
115
apiVersion: v1
100
116
kind: Secret
101
-
metadata:
117
+
metadata:
102
118
name: devstack-credentials
103
119
namespace: default
104
120
stringData:
@@ -109,79 +125,98 @@ stringData:
109
125
"ca_cert": "pem-encoded-ca-cert"
110
126
```
111
127
112
-
The OpenStack source reconciliation process attempts to list VMs in the project and marks the source as ready.
128
+
The OpenStack source reconciliation process attempts to list VMs in the project
129
+
and marks the source as ready.
113
130
114
131
```shell
115
132
$ kubectl get opestacksource.migration
116
133
NAME STATUS
117
134
devstack clusterReady
118
135
```
136
+
</TabItem>
137
+
</Tabs>
119
138
120
139
### VirtualMachineImport
121
-
The VirtualMachineImport CRD provides a way for users to define a source VM and map to the actual source cluster to perform VM export/import.
140
+
141
+
The VirtualMachineImport CRD provides a way for users to define a source VM and
142
+
map to the actual source cluster to perform VM export/import.
122
143
123
144
A sample VirtualMachineImport looks like this:
124
145
146
+
<Tabs>
147
+
<TabItem value="vmware" label="VMWare" default>
125
148
```yaml
126
149
apiVersion: migration.harvesterhci.io/v1beta1
127
150
kind: VirtualMachineImport
128
151
metadata:
129
152
name: alpine-export-test
130
153
namespace: default
131
-
spec:
154
+
spec:
132
155
virtualMachineName: "alpine-export-test"
156
+
folder: "/vm-foler"
133
157
networkMapping:
134
-
- sourceNetwork: "dvSwitch 1"
135
-
destinationNetwork: "default/vlan1"
136
-
- sourceNetwork: "dvSwitch 2"
137
-
destinationNetwork: "default/vlan2"
138
-
sourceCluster:
158
+
- sourceNetwork: "dvSwitch 1"
159
+
destinationNetwork: "default/vlan1"
160
+
- sourceNetwork: "dvSwitch 2"
161
+
destinationNetwork: "default/vlan2"
162
+
sourceCluster:
139
163
name: vcsim
140
164
namespace: default
141
165
kind: VmwareSource
142
166
apiVersion: migration.harvesterhci.io/v1beta1
167
+
storageClass: "harvester-longhorn"
143
168
```
144
169
145
-
This will trigger the controller to export the VM named "alpine-export-test" on the VMWare source cluster to be exported, processed and recreated into the harvester cluster
146
-
147
-
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.
148
-
149
-
The list of items in `networkMapping` will define how the source network interfaces are mapped to the Harvester Networks.
150
-
151
-
If a match is not found, each unmatched network interface is attached to the default `managementNetwork`.
152
-
153
-
Once the virtual machine has been imported successfully, the object will reflect the status:
154
-
155
-
```shell
156
-
$ kubectl get virtualmachineimport.migration
157
-
NAME STATUS
158
-
alpine-export-test virtualMachineRunning
159
-
openstack-cirros-test virtualMachineRunning
160
-
161
-
```
162
-
163
-
Similarly, users can define a VirtualMachineImport for an OpenStack source as well:
164
-
170
+
This will trigger the controller to export the VM named "alpine-export-test"
171
+
from the folder "/vm-folder" on the VMWare source cluster to be exported,
172
+
processed and recreated into the harvester cluster
173
+
</TabItem>
174
+
<TabItem value="openstack" label="OpenStack">
165
175
```yaml
166
176
apiVersion: migration.harvesterhci.io/v1beta1
167
177
kind: VirtualMachineImport
168
178
metadata:
169
179
name: openstack-demo
170
180
namespace: default
171
-
spec:
181
+
spec:
172
182
virtualMachineName: "openstack-demo" #Name or UUID for instance
183
+
folder: "/vm-folder"
173
184
networkMapping:
174
-
- sourceNetwork: "shared"
175
-
destinationNetwork: "default/vlan1"
176
-
- sourceNetwork: "public"
177
-
destinationNetwork: "default/vlan2"
178
-
sourceCluster:
185
+
- sourceNetwork: "shared"
186
+
destinationNetwork: "default/vlan1"
187
+
- sourceNetwork: "public"
188
+
destinationNetwork: "default/vlan2"
189
+
sourceCluster:
179
190
name: devstack
180
191
namespace: default
181
192
kind: OpenstackSource
182
193
apiVersion: migration.harvesterhci.io/v1beta1
194
+
storageClass: "harvester-longhorn"
183
195
```
184
196
185
-
:::note
186
-
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.
187
-
:::
197
+
:::note
198
+
OpenStack allows users to have multiple instances with the same name. In such a
199
+
scenario, users are advised to use the Instance ID. The reconciliation logic
200
+
tries to perform a name-to-ID lookup when a name is used.
201
+
:::
202
+
</TabItem>
203
+
</Tabs>
204
+
205
+
This can take a while based on the size of the virtual machine, but users should
206
+
see `VirtualMachineImages` created for each disk in the defined virtual machine.
207
+
208
+
The list of items in `networkMapping` will define how the source network
209
+
interfaces are mapped to the Harvester Networks.
210
+
211
+
If a match is not found, each unmatched network interface is attached to the
212
+
default `managementNetwork`.
213
+
214
+
Once the virtual machine has been imported successfully, the object will reflect
0 commit comments