@EddieJennings said in ScreenConnect agent on Fedora fails rpm install:

I read this as never install RPMs directly, which wouldn't make sense, because for some things, such as ScreenConnect, create RPMs on demand; thus, they'd never be in a repo -- As Jared mention.

You read it correctly. My point is, best practice is to always use yum, even for standalone RPMs, because $reasons (and if there are deps, yum will automatically resolve them). Even if the best practice is not applicable and you have a completely standalone package there, it's best to stick to best practices, just like you put on a seatbelt even when you drive 20 yards to your mailbox and back.

@JaredBusch said in ScreenConnect agent on Fedora fails rpm install:

And this just reinforces that you have no idea what you are talking about.

If you had any clue, you would realize that this is a on the fly create RPM to install the client software specific to the installation it was created from.

There is no way possible for this to ever be involved in a repository in any fashion whatsoever.

What I pointed at is the best practice for ANY RPM file. In this particular case you may be right, but if you deal with RPM based systems as much as I do, you'd do well to drop the attitude, you might actually learn something.

@EddieJennings said in ScreenConnect agent on Fedora fails rpm install:

Why not?

Because if you ever start using a proper repo for further updates to the package, you'll have to clean it up manually first. The RPM and all of its dependencies. Manually. That's a nice way to mess up a well configured system, in the long run.

yum localinstall (the "local" part is optional as of RHEL6, for the nitpicky types here) places the package in the yum db, so if you make a newer one available in a repo, updates will happen naturally. Removing it and it's dependencies will also be as simple as yum remove.

@JaredBusch said in ScreenConnect agent on Fedora fails rpm install:

You have no idea what you are talking about.

I didn't say it would work. I only said standalone RPM installs can be problematic in a yum/dnf managed system. But cheers on being an @hole, well done

Installing an RPM directly is never a good idea. What happens when you run yum localinstall package.rpm?

https://github.com/vladzcloudius/diskplorer

This is a cool wrapper for FIO, written by a colleague of mine. FIO provides you with the maximums, while this tool will allow you to measure the optimal settings and actual disk capabilities.

@scottalanmiller said in What would your recommendation be for a Type 1 Hypervisor - including backup and restoration options:

What issue are you seeing with full container virtualization for your workloads? You are modifying the kernels?

I need to have a proper, accessible and full /proc for one

@scottalanmiller said in What would your recommendation be for a Type 1 Hypervisor - including backup and restoration options:

Which part, the making more money part?

The part where you create containers and VMs from the same interface

@scottalanmiller my take is that they don't really see it as a huge advantage. And they recognize customers like me, who need to run a proper OS and not a container. They also don't really care about what OS that will be.

To put it in agile task terms: as a user, I want to be able to run an OS and perform actions the same way as if I'd be doing that on real hardware. As a developer, want to develop a product that works on my test machines, and then deploy on AWS or GCP without surprises. As a developer I want to develop in the cloud, and know that my code will work on my clients' machines properly.

So this is not really about windows, this is about providing a proper guest and not a husk like a docker runtime.

@scottalanmiller the really big providers also don't care about the cost of adding a feature like I mentioned earlier (if linux deploy on container, else deploy on VM), but they still default to VMs, despite the potential of such a feature to save them money due to better density and resource utilization

@scottalanmiller I don't use Vultr, so speak for yourself:) I also don't use Windows. But I use a lot of Linux on AWS and GCP as well as some openstack platforms. for me what is important isn't the ability to run Windows but the ability to run a proper OS and not a container, plus the more interesting instance types, like the i3.metal.

@scottalanmiller never even heard of HostFav, there are tons of small time providers out there, can't really cover them all.

@scottalanmiller well, in any case - that's where you get KVM from most providers. You want docker - you either deploy your own on cloud VMs or use GKE or whatever. I've never even seen LXC as an option

@scottalanmiller no, that's because there aren't any LXC-based VPS hosting solutions out there Even OVZ is more common

@scottalanmiller said in What would your recommendation be for a Type 1 Hypervisor - including backup and restoration options:

Most, but Windows is a taint here. Any Windows means you need KVM. Even if only one out of thousands of workloads. Unless you want different solutions for different workloads, which a lot of places want to avoid.

A cloud provider can potentially create a system where if you pick Linux you get a container and if you pick Windows you get a VM, sure. But that's not how this is done today. Most cloud providers don't even touch containers outside a container specific system, like AKS/GKE (or the old school VPS based on Parallels/OVZ). Instead they simply give you a choice of guest OS and instance type, and you always get a proper VM.

@scottalanmiller said in What would your recommendation be for a Type 1 Hypervisor - including backup and restoration options:

Most of those are Windows focused. If they didn't want to support Windows, they'd go to LXC. KVM is a lot of overhead that only makes sense when Windows is in their game plans, or potentially ISO support. Vultr and OpenStack are almost completely doing this because of their Windows options. IMHO

No, not at all. There is a fair bit of Windows used here and there, but the main guest OS is Linux.

LXC is actually very rare in production (LXD is even rare-er).

@scottalanmiller its basically just a replacement for QEMU, still using the same KVM, but more lightweight and much faster. Less features of course. So you end up with a lightweight (compared to QEMU) emulation plus a KVM hypervisor.

@scottalanmiller said in What would your recommendation be for a Type 1 Hypervisor - including backup and restoration options:

KVM's focus is definitely Windows workloads that are bloated and can't be made thinner like we see in the Linux world.

Not really, I see a lot of KVM on large public openstack deployments (think digitalocean or vultr or whatever) and also in private DCs. Been migrating customers from VMWare and Xen to KVM for years, probably tens of thousands of hosts, if not hundreds, with most of those workloads being Linux VMs. That is pretty much where containers are taking a bit out of all other hypervisors' pie, with workloads becoming shorter lived and more ad-hoc and micro-servicy, this tendency will only grow.

@scottalanmiller I frankly doubt there is much of a chance for Xen making anything worthwhile these days. With containers taking over most workloads and things like firecracker popping up, even KVM is losing ground. Openstack, the main locomotive for KVM adoption, isn't the cool new cloud platform any longer, and even it is adopting k8s and containers under the hood.

I think virtualization will become a niche platform technology in a few years, and if MS keep at their current direction, we might even see a common platform, where MS Windows 25 and Linux have the same base kernel and can easily run in the same container. We'll see

@scottalanmiller oh there are SOME drivers in those separate kernels, else they wouldn't be able to work at all.