nix: add cross-version migration tests

[arctic-alpaca]

Adds a new input for the previous version of cloud-hypervisor and passes that to the version_migrationtest. Theversion_migrationtest just runs the existinglive_migration` tests for two different cloud-hypervisor versions.

I've limited this PR to the live_migration tests, but long_migration_with_load can be done the same way.

I'm not sure if the nix: prefix is correct here.

Link to PR for libvirt: https://gitlab.cyberus-technology.de/cyberus/cloud/libvirt/-/merge_requests/153

To verify the behavior, I used a cloud-hypervisor branch that panics on migration. In CI, this shows only the newly added tests failing (timing out), which means the current cloud-hypervisor version is untouched, but the previous version is set as expected: https://gitlab.cyberus-technology.de/cyberus/cloud/libvirt/-/merge_requests/152

[hertrste]

Shouldn't it be possible to reuse the existing extraControllerConfig parameter and do something like the following? This would save us from having to pass-through those new parameters. Or do I miss something?

extraControllerConfig = [ {...}: {
  nixpkgs.overlays = [
    (
      _final: _prev:
      (lib.optionalAttrs (cloud-hypervisor-override != null)) {
        # Overwrite the default cloud-hypervisor version.
        cloud-hypervisor = cloud-hypervisor-override;
      }
    )
  ];
};
];

Sorry for the slightly off formatting of the snippet. I have not tested if the snippet works. Just to transport my thought.

[arctic-alpaca]

I'll look into it 👍 I'm not very familiar with Nix yet.

[hertrste]

I'll look into it 👍 I'm not very familiar with Nix yet.

Ah okay I see :D I'll hope it works correctly because I am not 100% sure how the overlays are applied in that case. But just give it a try and if it works as expected, we can remove the custom chv-override parameter again :)

[arctic-alpaca]

Way better, thank you!

[phip1611]

I'm not sure if the nix: prefix is correct here.

I personally use flake for purely flake-related stuff (adding dependency, bumping) and nix for everything else which is related to nix

[hertrste]

Very nice 👍 Pls reference this branch here in your libvirt MR so we can see the test runs successfully in the CI

[phip1611]

I think you can use a function here:

let
  toDebugOptimizedChv = drv: drv.overrideAttrs (old: {
              env = (old.env or { }) // {
                CARGO_PROFILE_RELEASE_DEBUG_ASSERTIONS = "true";
                CARGO_PROFILE_RELEASE_OPT_LEVEL = 2;
                CARGO_PROFILE_RELEASE_OVERFLOW_CHECKS = "true";
                CARGO_PROFILE_RELEASE_LTO = "thin";
              };
in
...
cloud-hypervisor-prev = toDebugOptimizedChv cloud-hypervisor-prev.packages.default

[hertrste]

Shouldn't the CHV flake expose that attribute itself already?

[phip1611]

Nope, the debug optimized build configuration is something that we have in libvirt-tests only.

[arctic-alpaca]

Does 43a5e95 match what you had in mind?

[phip1611]

perfect, yes

[phip1611]

I don't think this is what we want to have here. We want to have both cloud hypervisors in the same system config

I currently don't know what is the best solution but I think we want to end up with something like:

let
  renameBinsOld = inputDrv:
    pkgs.runCommand "${inputDrv.pname or inputDrv.name or "renamed"}-old-suffixed" {} ''
      mkdir -p $out
      cp -a ${inputDrv}/. $out/

      if [ -d "$out/bin" ]; then
        for f in "$out"/bin/*; do
          [ -e "$f" ] || continue
          mv "$f" "$f-old"
        done
      fi
    '';
  cloud-hypervisor-old' = renameBinsOld cloud-hypervisor-old; 
in
...

which would rename every binary to -old, so cloud-hypervisor-old and ch-remote-old. I'm open to discuss and plan this. What does @hertrste think?

[amphi]

We want to have both cloud hypervisors in the same system config

Why?

[phip1611]

Hm, am I missing something? We need both CHVs in PATH to chose which one we use to boot the VM. We use the same image in controllerVM and computeVM, right?

In case we have dedicated images on both VM hosts for this specific test (I don't know if this is easily possible with our current setup?) then things are different of course.

I'd love if the top-level motivation could better explain the design in that regard -

[amphi]

The CHV version for the controller VM is overwritten in tests/default.nix.

[hertrste]

Hm, am I missing something? We need both CHVs in PATH to chose which one we use to boot the VM. We use the same image in controllerVM and computeVM, right?

I think you are missing were this nixos module is put:

      extraControllerConfig = [

We just change the overlay for CHV in the controllerVM. Thus, the controller uses the old version while the compute uses the new (aka default) one.

[phip1611]

ah okay, makes sense! thanks!