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