[BUG] Debian: netlab won't start with libvirt provider

[benbgg]

Describe the bug

OS: Debian bookworm netlab won't start with libvirt provider

To Reproduce

netlab test -v libvirt fails after which kvm-ok Most of the bugs are caused by an error in the data transformation code or templates -- the data structures or device configurations generated by netlab are not what you would expect (which should have been described in the above section).

If you're experiencing any other unexpected behavior, please add the steps needed to reproduce it.

Expected behavior

test cumulus 3 vm node topology supposed to start. Output: ┌──────────────────────────────────────────────────────────────────────────────────┐ │ CHECKING libvirt installation │ └──────────────────────────────────────────────────────────────────────────────────┘ [FATAL] KVM is not installed

Lab topology

built-in test Please add the minimum lab topology needed to reproduce the bug

### Output

Please add the output you get when running netlab create on the minimum lab topology provided

Output:
┌──────────────────────────────────────────────────────────────────────────────────┐
│ CHECKING libvirt installation                                                    │
└──────────────────────────────────────────────────────────────────────────────────┘
[FATAL]   KVM is not installed

### Version

* netlab version (as displayed by `netlab version`)
* netlab version 1.8.2

### Additional context
Fix/ workaround: ln -s /usr/sbin/kvm-ok /usr/bin/kvm-ok

Add any other context about the problem here.

[ipspace]

Do I understand it correctly that kvm-ok on Debian is in /usr/sbin (like on Ubuntu), but (contrary to Ubuntu), /usr/sbin is not in the path?

Would it be OK to document a workaround (like we did for Fedora/AlmaLinux) saying "on Debian, make sure /usr/sbin is in your path"?

[ipspace]

Alternatively, we could run sudo which kvm-ok and sudo kvm-ok, but that would require that the netlab user is a sudoer, which is not strictly required for libvirt labs using only P2P links (but is a prerequisite for LAN links or containerlab labs).

What do you think @ssasso @ghostinthenet

[ssasso]

I think we can have two options:

1) document the fact that you must have /usr/sbin in your path. 2) force the full path of the binary - I don't think this will change in the future.

OTOH, if you want to force the command with sudo, then you don't need to call which, but sudo kvm-ok is enough.

[ipspace]

1. OK, I'm going with the full path to the binary, and that kvm-ok is in /usr/sbin and will use type instead of which
2. We need to check for the presence of kvm-ok to differentiate between KVM is not installed and KVM is not enabled

Also, I will add instructions describing how to disable the installation checks.

[benbgg]

OK, just for a bit of context: This came about as I got the Debian "external package" alarm - so I was trying to go down the Venv route with my user added to all required groups. I'm not a python3/ pip expert, so feel free to say "what were you thinking" - or other feedback. Thanks for the package!

[ipspace]

This came about as I got the Debian "external package" alarm - so I was trying to go down the Venv route with my user added to all required groups.

That's perfectly OK as long as you understand that you're outside of the supported path (but of course we'll either document your findings or implement fixes if they make sense)

I'm not a python3/ pip expert, so feel free to say "what were you thinking" - or other feedback. Thanks for the package!

Thanks for pointing out another gotcha. Please keep them coming ;) Already implemented the fix, working on documenting the workarounds right now, after that it goes into the dev branch (and you will be able to pull down the Git repo to test it: https://netlab.tools/install/clone/)