2022-v2v-in-kubevirt/notes.txt

   1 Virt-v2v in Kubevirt
   2 ====================
   3
   4 (0) What is it
   5
   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.
   9
  10 Supports Windows and some Linux distros.
  11
  12 First version of virt-p2v was written in 2007(!)  We've been
  13 serious about it since about 2008/2009.
  14
  15
  16 (1) Virt-v2v is a process, not a step
  17
  18 Many different types of inputs supported:
  19
  20 * VMware over HTTP
  21
  22 * VMware over VDDK
  23
  24 * VMware over SSH
  25
  26 * Xen
  27
  28 * local disk files
  29
  30 * OVA files (GUI export or ovftool)
  31
  32 * local VMX files
  33
  34 * libvirt
  35
  36 * from physical machines (p2v*)
  37    *slightly different process
  38
  39 Command line is complicated, but stick to the documentation and
  40 you'll be fine.
  41
  42
  43 (2) Correctness, supportability
  44
  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.
  48
  49 Metadata == VMware VMX data on the input side
  50          == Kubevirt YAML on the output side
  51
  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.
  55
  56 We only support virt-v2v when used as directed.
  57
  58 I'm the one who does third line support when things go wrong.
  59
  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
  62 on any more.
  63
  64
  65 (3) What we've tried
  66
  67 Modified Tomas's example volume populator
  68 (https://github.com/nyoxi/vmware-populator) so that it just runs
  69 virt-v2v.
  70
  71 => Ugly having to pass virt-v2v args
  72
  73    * could be cleaned up with some CRDs
  74
  75 => Only a single disk supported
  76
  77 => No place to write out the metadata
  78
  79 => Have to specify the size up front
  80
  81 => How to report errors?
  82
  83 => Possible we could use a filesystem PVC and write out:
  84
  85     * disk1.qcow2
  86     * disk2.qcow2
  87     * guest.yaml
  88     * virt-v2v.log
  89
  90    but would involve an extra copying step (or else modifying
  91    Kubevirt to be able to boot from this).
  92
  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
  96      first pass.
  97
  98
  99 (4) What we also talked about
 100
 101 Could we just run virt-v2v in a pod?
 102
 103 => It would do the conversion and run kubectl / virtctl commands
 104    in order to create resources and the final guest as needed.
 105
 106 => Cannot create PVCs
 107
 108 Can we chain pods together?
 109
 110 => One pod sets up the PVCs, second pod does the conversion and
 111    finishes up.
 112
 113 I feel we are missing some "automation" thing in Kubernetes.
 114 Is this what operators are?
 115
 116
 117 (5) Miscellaneous
 118
 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.
 121
 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.)