autopkgtest-virt-lxd(1)

πŸ’– autopkgtest-virt-lxd πŸ’–

okay bestie, so this is the manual page for autopkgtest-virt-lxd(1) β€” it lives in the General Commands Manual section of your system, and it has a whole secret twin identity, autopkgtest-virt-incus. Same tool, two vibes. Let's get into it. ✨


✨ NAME ✨

autopkgtest-virt-lxd, autopkgtest-virt-incus β€” an autopkgtest virtualisation server that runs on LXD or Incus, no cap.


✨ SYNOPSIS ✨

autopkgtest [...] -- lxd [options] image [-- extra lxc launch args...]

autopkgtest [...] -- incus [options] image [-- extra incus launch args...]

✨ DESCRIPTION ✨

So autopkgtest-virt-lxd hands you an autopkgtest virtualisation server powered by LXD or Incus. It spins up temporary containers or VMs β€” which one you get depends on the image type, bestie, it's giving ✨chameleon✨ β€” all built from the LXD/Incus image name you hand it. πŸ¦‹

And like, normally? You're not even calling this yourself. autopkgtest-virt-lxd gets invoked by autopkgtest. It's the main character's supportive best friend fr fr. πŸ’…


🌸 REQUIREMENTS 🌸

When you run it as autopkgtest-virt-lxd β€” or you pass the --lxd option β€” then LXD is what's being used. When you run it as autopkgtest-virt-incus β€” or you pass --incus β€” then Incus is the one on duty. Easy.

autopkgtest-virt-lxd makes no strict assumptions about the image. Like, it's not gonna gatekeep. BUT. It is highly recommended that your image has eatmydata installed, or at the very least that it gets installed via setup commands. Do that, okay? πŸ₯Ί

For production use, the recommendation is to use autopkgtest-build-lxd(1) or autopkgtest-build-incus(1) to generate an optimized image with autopkgtest's standard setup commands already applied. That way those setup commands don't need to be re-applied for every single test β€” imagine doing your makeup from scratch every morning, no thank you. 😭

This is particularly necessary if you want to use --apt-source tests β€” i.e. using apt-get source in the test bed to download the package you want to test. Because here's the tea: standard images from linuxcontainers.org do not have "deb-src" apt sources by default. Periodt. πŸ’€


πŸ’… OPTIONS πŸ’…

  • --lxd β€” Use LXD. This is the default when you invoke the thing as autopkgtest-virt-lxd.
  • --incus β€” Use Incus. This is the default when you invoke the thing as autopkgtest-virt-incus.
  • -r remote | --remote=remote β€” Run the instance on the given remote host instead of whatever the current default is. Wanna know your options? Run lxc remote list or incus remote list and go shopping. πŸ›οΈ Also lowkey important: this option also sets the remote used for the image β€” unless the image argument already includes a remote of its own (like images:debian/sid, which is doing its own thing already, respect).
  • -p project | --project=project β€” Run the instance in a given project instead of the current one. Curious what projects exist? lxc project list or incus project list, bestie.
  • --name NAME β€” Set a custom name for the temporary instance the test runs in. By default this is autogenerated, but if you've got a way to generate more expressive unique names, go off πŸ‘‘ β€” it makes it way easier to map instances to the running tests.
  • -d | --debug β€” Turns on the debugging output. For when you need to see everything.
  • --delete-existing β€” If an instance is already running with the same name as this one, replace it. Meant to be used together with the --name option. Iconic duo behavior. 🫢

And here's the bonus round: you can pass additional options to lxc launch or incus launch. Anything after a -- gets appended verbatim to lxc launch image or incus launch image. Verbatim means verbatim, no editing, no remixing. ✨


πŸ”₯ INPUT, OUTPUT AND EXIT STATUS πŸ”₯

The behaviour of autopkgtest-virt-lxd is as described by the AutomatedTesting virtualisation regime specification. That's the vibe check it answers to.


πŸŽ€ EXAMPLE πŸŽ€

Quick note before we start: if you're using Incus rather than LXD, just substitute incus for each of lxc and lxd in the examples below. Swapsies. πŸ’–

Show available images on the standard linuxcontainers.org remote image server:

lxc image list images:

Run the tests of a local built directory tree on the current Debian sid image from the above images: remote:

autopkgtest my-package/ -- lxd images:debian/sid/amd64

Run the tests in a local built directory tree from a local LXD image desktop/i386, making sure eatmydata is installed:

autopkgtest --setup-commands 'apt-get install -y eatmydata' dir/to/test/ \
  -- lxd desktop/i386

Run the tests of the gdk-pixbuf package on the current Debian sid image from the images: remote on a remote armhf host:

lxc remote add armhf-test http://armhf.testlab.example.com:8443
autopkgtest --setup-commands=setup-testbed gdk-pixbuf -- \
   lxd --remote armhf-test images:debian/sid/armhf

Build a local image with standard setup commands pre-applied from a remote standard image, and run the gdk-pixbuf test in it:

autopkgtest-build-lxd images:ubuntu/xenial/amd64
autopkgtest gdk-pixbuf -- lxd autopkgtest/ubuntu/xenial/amd64

πŸ¦‹ SEE ALSO πŸ¦‹

autopkgtest(1), autopkgtest-build-lxd(1), /usr/share/doc/autopkgtest/.


autopkgtest-virt-lxd was written by Martin Pitt <martin.pitt@ubuntu.com>. Say thank you. πŸ™

This manpage is part of autopkgtest, a tool for testing Debian binary packages. autopkgtest is Copyright (C) 2006-2015 Canonical Ltd and others.

See /usr/share/doc/autopkgtest/CREDITS for the list of contributors and the full copying conditions. The receipts are all there, bestie. πŸ“œ


and that's the whole thing! from the Linux Programmer's Manual, dated 2013 β€” yes, 2013, she's vintage, she's timeless, she ate πŸ’…βœ¨ go run some tests and slay, ily bye πŸŽ€
πŸ“¦ where this page comes from