What’s the recommendations when running lxd in a virtual environment?
For example on ubuntu (which i will base this on) there is a kernel called: linux-azure
I can’t really tell if it’s just meant for azure itself or not, but it seems to indicate it’s also meant for hyper-v.
And if that’s the case, would one want that on the host (lxd host) as well as the containers?
Or would that be bad cause of how it shares the kernel and whatnot?
I also wonder about the filesystems,
i currently use the defaults on ubuntu server which i think is ext4 with LVM.
And when using “lxd init” it defaults to zfs for the storage pool, but i believe that filesystem expects direct storage access for it to do it’s thing correctly, which i doubt hyper-v really allows.
So i change it to brtfs in belief that it’s the better choice, but i rather know from the better folks than just assuming it’s great.
— Random ramble below, you have been warned —
Apart from that, i will just say that i find LXC/LXD to be very interesting and had really good experience with it so far!
Now being a debian person it’s a bit “hard” to use ubuntu, but as that’s what it has been made for it’s probably for the better, and i do think i like some parts of ubuntu compared to debian, so gotta thank you for making me experience something “different” haha
Containers always share their host kernels, that’s what makes them containers.
I can’t really speak of whether the azure kernel is a better fit for HyperV environments than the normal generic kernel as I don’t know what the config difference really is.
In general, I’d probably recommend using the generic kernel and only switching to one of the others if you encounter something specific that’s missing.
btrfs vs zfs shouldn’t really matter, in either case you’ll get a loop block storage setup.
Both of them would prefer to use a dedicated virtual disk, or partition or LVM LV if one is available as that avoids the whole loop device overhead.
If you prefer Debian, we have quite a few users running LXD on it. You can just install the snapd package from the Debian archive and then do snap install lxd as you would on Ubuntu. It’s something we actively test, alongside a lot of other distributions. lxd-test-snap-latest-stable [Jenkins]
The only real difference from our point of view when using the snap on a different distribution is the kernel provided by that distribution. We obviously have a tighter feedback loop with the Ubuntu kernel team, so the Ubuntu kernel tends to get some of the new features we’d like to use backported and enabled quite early while support on other distros will depend on what their individual kernel teams decide.
