2021-pipelines/notes.txt

   1 Disk Image Pipelines
   2 February 15th 2021
   3 ======================================================================
   4
   5 Introduction
   6 ----------------------------------------------------------------------
   7
   8 Today I'm going to talk about a topic which seems very obvious to me.
   9 But I work in the business of moving disk images between systems, and
  10 it may not be obvious to other people.
  11
  12 INTRO INTRO INTRO
  13 INVOLVE PIPELINES DIAGRAM
  14
  15 The bad:
  16  - creating unbounded temporary files
  17  - slow copies
  18
  19
  20
  21 Simple copying
  22 ----------------------------------------------------------------------
  23
  24 Let's start with something trivial: Let's boot a virtual machine from
  25 a local disk image.  Normally I'd say use libvirt, but for this demo
  26 I'm going to get very simple and run qemu directly.
  27
  28 DIAGRAM:
  29
  30   local file -> qemu
  31
  32   qemu-system-x86_64 -machine accel=kvm:tcg -cpu host
  33                      -m 2048 -display none \
  34                      -drive file=fedora-33.img,format=raw,if=virtio \
  35                      -serial stdio
  36
  37
  38 DIAGRAM:
  39
  40          ssh
  41   file -------> qemu
  42
  43 A lesser-known fact about qemu is that it contains an SSH client so
  44 you can boot from a remote file over SSH:
  45
  46 COMMAND:
  47
  48   qemu-system-x86_64 -machine accel=kvm:tcg -cpu host
  49                      -m 2048 -display none \
  50                      -drive file=ssh://kool/mnt/scratch/fedora-33.img,format=raw,if=virtio \
  51                      -serial stdio
  52
  53
  54 Snapshots
  55 ----------------------------------------------------------------------
  56
  57 DIAGRAM:
  58
  59          ssh
  60   file -------> snapshot ------> qemu
  61
  62 That command opens the remote file for writes.  If we want to prevent
  63 modifications to the remote file, we can place a snapshot into the
  64 path.  A snapshot in this case is a qcow2 file with the backing file
  65 set to the SSH URL.  Any modifications we make are saved into the
  66 snapshot.
  67
  68 COMMAND:
  69
  70   qemu-img create -f qcow2 -b ssh://kool/mnt/scratch/fedora-33.img snapshot.qcow2
  71   qemu-system-x86_64 -machine accel=kvm:tcg -cpu host
  72                      -m 2048 -display none \
  73                      -drive file=snapshot.qcow2,format=qcow2,if=virtio \
  74                      -serial stdio
  75
  76
  77 Copying
  78 ----------------------------------------------------------------------
  79
  80 Instead of booting the disk, let's make a full local copy:
  81
  82 COMMAND:
  83
  84   qemu-img convert -f qcow2 snapshot.qcow2 -O raw disk.img -p
  85
  86
  87
  88 Sparsification
  89 ----------------------------------------------------------------------
  90
  91 DIAGRAM:
  92
  93   [ XXXXXXXXXX .... DDDDDDDD XXXXXXXXXXXX .......... ]
  94
  95 Now let's take side-step to talk about what's inside disk images.
  96
  97 Firstly disk images are often HUGE.  A BluRay movie is 50 gigabytes,
  98 but that's really nothing compared to the larger disk images that we
  99 move about when we do "lift and shift" of workloads from foreign
 100 hypervisors to KVM.  Those can be hundreds of gigabytes or terabytes,
 101 and we move hundreds of them in a single batch.
 102
 103 But the good news is that these disk images are often quite sparse.
 104 They may contain much less actual data than the virtual size.
 105 A lot of the disk may be filled with zeroes.
 106
 107 But the bad news is that virtual machines that have been running for a
 108 long time accumulate lots of deleted files and other stuff that isn't
 109 needed by the operating system but also isn't zeroes.
 110
 111
 112 We can cope with both of these things.  The technique
 113 is called "sparsification".
 114
 115   qemu-img create -f qcow2 -b ssh://kool/mnt/scratch/fedora-33.img snapshot.qcow2
 116   virt-sparsify --inplace snapshot.qcow2
 117   ls -l snapshot.qcow2
 118