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
Copy file name to clipboardExpand all lines: qemu_artifact.md
+5-72Lines changed: 5 additions & 72 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,68 +1,9 @@
1
1
# QEMU artifact
2
2
3
-
We build a container image that contains a QEMU qcow2 disk image. This container image can be use with KubeVirt's [containerDisk](https://kubevirt.io/user-guide/storage/disks_and_volumes/#containerdisk) functionality to boot up VMs off the qcow2 image.
4
-
5
-
Container images are a convenient mechanism to ship the disk image to the nodes where they're needed.
3
+
We build a container image that contains a QEMU qcow2 disk image. Container images are a convenient mechanism to ship the disk image to the nodes where they're needed.
6
4
7
5
Given the size of the image, the first VM using it on a node might take a while to come up, while the image is being pulled down. The image can be pre-fetched to avoid this; we might also switch to other deployment mechanisms in the future.
8
6
9
-
# Building QEMU artifact
10
-
11
-
## Creating a bare-metal instance
12
-
13
-
We launch an Ubuntu 22 bare-metal instance; we're using the `c6g.metal` instance type in this case, but any ARM instance type is sufficient for our purposes. In the example below the region used is: `ap-south-1`.
git checkout da/qemu-rebasing # choose appropriate branch here
63
-
make init container-disk-image
64
-
```
65
-
66
7
### Build process
67
8
68
9
The current AMI process involves a few steps:
@@ -87,21 +28,13 @@ b. packer build (`qemu-arm64-nix.pkr.hcl`)
87
28
88
29
## Publish image for later use
89
30
90
-
Following `make init container-disk-image`, the generated image should be found in: `/path/to/postgres/output-cloudimg`. For portability the image is also bundled up as a docker image with the name: `supabase-postgres-test` . Publish the built docker image to a registry of your choosing, and use the published image with KubeVirt.
91
-
92
-
# Iterating on the QEMU artifact
93
-
94
-
For a tighter iteration loop on the Postgres artifact, the recommended workflow is to do so on an Ubuntu bare-metal node that's part of the EKS cluster that you're deploying to.
31
+
Following `make init alpine-image`, the generated VM image should be bundled as a container image with the name: `supabase-postgres-test` . Publish the built docker image to a registry of your choosing, and use the published image with e.g. KubeVirt.
95
32
96
-
- Instead of running `make init container-disk-image`, use `make init host-disk` instead to build the raw image file on disk. (`/path/to/postgres/disk/focal-raw.img`)
97
-
- Update the VM spec to use `hostDisk` instead of `containerDisk`
98
-
- Note that only one VM can use an image at a time, so you can't create multiple VMs backed by the same host disk.
99
-
- Enable the `HostDisk` feature flag for KubeVirt
100
-
- Deploy the VM to the node
33
+
## Iterating on image
101
34
102
-
Additionally, to iterate on the container image part of things, you can build the image on the bare-metal node (`eks-node-container-disk-image` target), rather than needing to publish it to ECR or similar registry. However, this part can take a while, so iterating using host disks remains the fastest dev loop.
35
+
For faster iteration, it's more convenient to build the image on an ubuntu bare-metal node that's part of the EKS cluster you're using. Build the image in the `k8s.io` namespace in order for it to be available for immediate use on that node.
103
36
104
-
## Dependencies note
37
+
###Dependencies note
105
38
106
39
Installing `docker.io` on an EKS node might interfere with the k8s setup of the node. You can instead install `nerdctl` and `buildkit`:
0 commit comments