Build Appliance 2023

From Yocto Project
Revision as of 19:57, 13 April 2023 by Trevor Woerner (talk | contribs) (add page (not yet complete))
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search

Build

Using either poky or a no-distro oe-core simply run the following to generate the Build Appliance image:

$ bitbake build-appliance-image

At a minimum the configuration requires:

  • the MACHINE should be set to qemux86-64
  • DISTRO_FEATURES must include opengl, x11, xattr
  • VOLATILE_TMP_DIR must not be set to yes

Usage

Currently, building the build-appliance-image target generates the following artifacts (among others):

  • build-appliance-image*rootfs.wic.vhd
  • build-appliance-image*rootfs.wic.vhdx
  • build-appliance-image*rootfs.wic.vmdk

The resulting *vmdk should be runnable in any of:

  • qemu
  • virtualbox
  • vmware player

qemu

After successfully building the build-appliance-image, from the same shell from which the build was performed, run:

$ runqemu slirp kvm nographic serial tmp-glibc/deploy/images/qemux86-64/build-appliance-image-qemux86-64.wic.vmdk

To quit qemu non-gracefully use: Ctrl-A + x

virtualbox

vmware player

Issues

Qemu has support for virtio-blk and is using that. However, neither virtualbox nor vmware support virtio-blk. The ideal scenario would be to build one image, and for it to be usable in all virtualization platforms.

In-Appliance Build Performance

The goal is to build core-image-sato in each of the virtualization platforms and see which one is able to build the image the fastest.

Some virtualization platforms support some features, while other platforms support other features. On the one hand it would be great to build one image that can be usable in all virtualization platforms, on the other hand it would be nice to see how well these virtualization platforms perform when used optimally. As such, a number of tests will be performed and explained below in order to see how they compare to each other, and how they compare to a build done natively.

It's important to eliminate the effects of connectivity on the build time measurements. As such each run will start with a $ bitbake core-image-sato --runall=fetch before performing the actual $ bitbake core-image-sato build.

native

Virtualization platforms are not allowed to use all of the host's resources (CPU, memory). Therefore performing an unrestricted build on the host will not be the best comparison since none of the virtualized builds will have any chance of comparing; it won't be an apples-to-apples comparison.

qemu