gpg/ssh info

[TheFu]

The reason to avoid creating VMs BEFORE doing a planned system upgrade to a new distro, is because the qemu-virtual-machine used will be for the older release. For Linux distros, changing the motherboard model to a newer one isn't an issue that I've had, but for some commercial OSes, like that "other OS", you'll be stuck with the old fake motherboard, perhaps for decades, since changing the motherboard will invalidate the license. For example:

Win7Ult.xml:    <type arch='x86_64' machine='pc-i440fx-trusty'>hvm</type>
WinXPPro.xml:    <type arch='x86_64' machine='pc-i440fx-xenial'>hvm</type>

If I change those, bad things happen, like license reactivation is mandated.

So, when USB5 becomes available and your OS was installed with USB2/3 as the only known options, then the newer hardware won't support the faster connectivity.

Just something to consider.

[kevdog]

Is lxd an Ubuntu thing or is this taken from Debian (as I'm aware Proxmox can run this type of containerization). Can I use this type of virtualization on Fedora?

[TheFu]

Is lxd an Ubuntu thing or is this taken from Debian (as I'm aware Proxmox can run this type of containerization). Can I use this type of virtualization on Fedora?

Don't confuse LXC and LXD. LXD is a Canonical management system, deployed as a snap package on any Linux platform.

LXC was the original name of Linux Containers from 2013 times. https://en.wikipedia.org/wiki/LXC Basically, from 2.6.24 and later, the ability to have cgroups and namespaces has been part of the Linux kernel. It really wasn't until the 3.8 kernels that it took off (to my recollection). Early versions used the host root user and it was possible for the container to modify things on the host. Non-root containers weren't easily available for many years. Docker created "privileged containers" for many years, which any security conscious person would consider a non-starter for that technology and choose full VMs. I think 3.11 finally allowed unprivileged containers, with some support packages.

Canonical seems to be backing the lxc project now and the core developers for lxc and lxd overlap.

Clear as mud?

https://discourse.ubuntu.com/t/lxd-4...existing/15222 can help understand how libvirt, lxd, kvm can be used together. There are many, many, many, things I like about lxd and a few things that are Canonical choices which I disagree concerning. That link has actual commands to setup an lxd system and create a few lxd containers and kvm VMs. Importation of existing VMs might be possible. I've never looked into that.

Think of lxd as a replacement for libvirt and virsh.

[DuckHook]

Is lxd an Ubuntu thing or is this taken from Debian (as I'm aware Proxmox can run this type of containerization). Can I use this type of virtualization on Fedora?

To my very, very limited knowledge, Proxmox indeed runs LXD and so does Fedora. I'm talking about LXD in the sense that TheFu is: the management platform on top of which all of that namespace magic happens. In the case of Proxmox, they've chosen to piggyback much of their functionality on LXD. So they have made a deep commitment to the LXD platform and have tied their fortunes to it.

In the case of Fedora, it's just another container option. They are supporting it as an alternative to Docker.

The results are the same but the motivation is quite different. I have confidence that Proxmox will continue to support LXD; less so about Fedora.

[kevdog]

Thanks @DuckHook and @TheFu. Still looking into exploring lxd/lxc. I just don't want to be stuck with a container or virtualization system that unfortunately is only applicable to Ubuntu.

[TheFu]

Thanks @DuckHook and @TheFu. Still looking into exploring lxd/lxc. I just don't want to be stuck with a container or virtualization system that unfortunately is only applicable to Ubuntu.

It will work on any Linux that supports snaps and has the appropriate CPU architecture. LXD will work places that KVM does not, providing you can meet the snap requirements (which many of my systems cannot).

[kevdog]

@TheFu

Honestly hate the direction Ubuntu is going with the snap requirements. Not trying to beat a dead horse here but it seems like they are treading uphill alone on the snap implementation on this one. I like virtualization solutions however I don't like one that locks me into specific linux distributions.

[TheFu]

Sorry if it isn't clear, but snaps are NOT specific to any Linux distro, therefore lxd isn't specific to any Linux distro.

Sure, I'd much prefer that lxd and the included lxc be normally packaged, without snaps. Then it would work on more of my systems, but for most home users, with reasonable CPU, RAM, and storage, snaps are probably a good thing.

Canonical decided that allowing too many controls for most people just makes them anxious. That doesn't make grandma prefer Ubuntu, which I fear is Canonical's target user. Well, grandmas and IoT device makers.

For me and my use, snaps are an abomination. I put up with a few and purge most systems of any snap stuff. I'll probably be switching desktops from Ubuntu in my next upgrade to avoid snaps. Have about a year before that is forced. Servers are a harder choice for me.

[#&thj^%]

but for most home users, with reasonable CPU, RAM, and storage, snaps are probably a good thing.

For me the jury is still out on that point.

[DuckHook]

For me the jury is still out on that point.

I feel snaps to be a mixed bag with the potential to get better (which gives me hope). However, in their current incarnation, I am forced to find workarounds, but only for some apps, so I can't condemn the entire platform.

I am in soft agreement with TheFu that they are probably a good thing for general home users with sufficient HW requirements. I applaud the idea of automatic default sandboxing. While this gives rise to certain complaints, we forum members need to guard against confirmation bias—in this case, negative confirmation bias. We hear only of the problems, but none of the successes, since people who are happy with their install rarely come on the forums to tell us how delighted they are. Likewise, the problems that sandboxing prevents (like stopping malware) aren't going to get mentioned either. How does one even recognize, much less report, the absence of a problem?

My only criticism of snaps is that there are not enough options to fine tune such sandboxing (including bypassing it altogether). I'm optimistic that this will get better with time.

In fact, the devs do recognize some of the issues arising from snaps and are slowly working on them. This just in: https://www.omgubuntu.co.uk/2022/05/...nap-app-faster