| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before this change, the s6 services for cloud-hypervisor and virtiofsd
were only started when a VM was started, and vm-stop would bring the
service down. The problem with this was that if a VM powered itself
off, instead of being stopped on the host using vm-stop, the VM would
instantly be restarted by s6.
To fix this, we disentangle keeping cloud-hypervisor running from
keeping the VM running. cloud-hypervisor will now always be running,
so s6 will never restart it in normal operation, but it won't be
running a VM until it's told to. Accomplishing this means having
start-vmm (renamed from start-vm to reflect its new purpose) configure
the VM in cloud-hypervisor without booting it, which is only possible
using the API, not the command line. As a result, start-vm now
depends on miniserde so that it can construct the VM config JSON
object required by the API.
The build of start-vm has been adjusted to accomodate the complexity
stemming from the new dependencies. Tests are moved into passthru,
because the start-vm used in Spectrum should have panic=abort, but
tests need panic=unwind, and we can't use both in the same Meson
instance without duplicating the non-native dependencies.
We can't use s6-rc dependencies to automatically boot provider VMs in
this setup, so vm-start has been modified to recurse into provider VMs.
lsvm has been updated to check the Cloud Hypervisor API to see whether
a VM is running, rather than just checking to see whether the s6
service is up.
Because cloud-hypervisor is now to be started as early as possible, we
need to make the dependencies of ext-rc-init more precise, so that
cloud-hypervisor does not attempt to start before /dev/kvm or
/dev/net/tun is available.
We're not using Meson's support for Cargo subprojects yet, because it
currently always builds crates with all features enabled.
Signed-off-by: Alyssa Ross <hi@alyssa.is>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
By default, a file called "config.nix" in the root of the Spectrum
repository will be read if it exists. That file should contain an
attribute set. Currently, only a "pkgs" key is supported, which
allows specifying a custom package set that will be used throughout
the Spectrum Nix files. This will allow us to provide configuartion
options for people who want to build Spectrum in ways that are
probably not suitable for upstreaming.
For example, using the "pkgs" config option I'm introducing here, it
would be possible to use an overlay to patch individual components,
like so:
{
pkgs = import <nixpkgs> {
overlays = [
(final: super: {
weston = super.weston.overrideAttrs ({ patches ? [], ... }: {
patches = patches ++ [
path/to/weston.patch
];
});
})
];
};
}
Signed-off-by: Alyssa Ross <hi@alyssa.is>
Message-Id: <20220831093727.282797-1-hi@alyssa.is>
Reviewed-by: Ville Ilvonen <ville.ilvonen@unikie.com>
Tested-by: José Pekkarinen <jose.pekkarinen@unikie.com>
|