6 Convert a virtual machine from VMware (usually) to run on KVM.
7 Involves installing the correct device drivers inside the guest
8 and making many other changes so it is bootable.
10 Supports Windows and some Linux distros.
12 First version of virt-p2v was written in 2007(!) We've been
13 serious about it since about 2008/2009.
16 (1) Virt-v2v is a process, not a step
18 Many different types of inputs supported:
30 * OVA files (GUI export or ovftool)
36 * from physical machines (p2v*)
37 *slightly different process
39 Command line is complicated, but stick to the documentation and
43 (2) Correctness, supportability
45 For a correct conversion, it's vitally important that we query
46 VMware for the full metadata, and also vital that the metadata
47 that virt-v2v writes is consumed by the target hypervisor.
49 Metadata == VMware VMX data on the input side
50 == Kubevirt YAML on the output side
52 Virt-v2v already knows how to do this, and also how to efficiently
53 copy the guest. There are many complex corner cases.
54 Don't duplicate this work.
56 We only support virt-v2v when used as directed.
58 I'm the one who does third line support when things go wrong.
60 I've been in several "difficult" calls with customers
61 when we've fucked up over the years, and I'm not keen on being
67 Modified Tomas's example volume populator
68 (https://github.com/nyoxi/vmware-populator) so that it just runs
71 => Ugly having to pass virt-v2v args
73 * could be cleaned up with some CRDs
75 => Only a single disk supported
77 => No place to write out the metadata
79 => Have to specify the size up front
81 => How to report errors?
83 => Possible we could use a filesystem PVC and write out:
90 but would involve an extra copying step (or else modifying
91 Kubevirt to be able to boot from this).
93 * The main point about reducing copies is reducing *remote* copies
94 because VDDK is expensive and finnicky. Local copies of fully
95 sparsified data within the target cluster may be acceptable for a
99 (4) What we also talked about
101 Could we just run virt-v2v in a pod?
103 => It would do the conversion and run kubectl / virtctl commands
104 in order to create resources and the final guest as needed.
106 => Cannot create PVCs
108 Can we chain pods together?
110 => One pod sets up the PVCs, second pod does the conversion and
113 I feel we are missing some "automation" thing in Kubernetes.
114 Is this what operators are?
119 We have an "-o kubevirt" output mode which generates Kubevirt YAML.
120 It's not upstream, but could be once we've decided what to do.
122 If we decide that some other process must create the PVC(s) in
123 advance, then virt-v2v needs a way to estimate the number/size
124 of disks needed. (We had this in the past and removed it, but
125 could add something again once it's clear what is exactly needed.)