3 ms·

>Please, dear Red Hat, just give me a DigitalOcean VM (or something comparable) that costs a few dollars more and has automatic RHEL licensing. Make deals with

>Please, dear Red Hat, just give me a DigitalOcean VM (or something comparable) that costs a few dollars more and has automatic RHEL licensing. Make deals with the VM providers, work something out. We've tried to make deals with RH in the past, but they will only let us sell RHEL VMs with licenses if it's running on a RHEL hypervisor... which none of our platform is using at all.

avhception 3y ago
That's sad. And we'd have to figure out what to do with the bare metal instances and containers, too.
freedomben 3y ago
I think this sucks, but for a little bit of defense of RH on this the entire support stack is built around assuming a RHEL host (meaning you're using a supported and exact version of the hypervisor and associated tools). Adding support capabilities for a non-RHEL host would be a major task, and not one they are well equipped to do. Now that said it's a bit dumb because with most things it's not hard for support to tell your customer, "yep that's a problem in the guest" and help, or "that's a problem with the host, contact DO" or whoever. But in general, when Red Hat says something is "supported" they are guaranteeing a lot about it. They'll literally fix the code if something is wrong. There's also a culture internally of "be careful helping with something that is 'unsupported'" because customers have previously accused RH people of messing stuff up and demanding they fix it. I helped with stuff like that most of the time when I worked for RH, but I was always very clear with the customer that "this isn't Red Hat, this is me helping as a friend and fellow Linux nerd" and the rapport with the customers was always good enough that I wasn't worried.
- progmetaldev 3y ago
  As someone who has done this, and benefitted from others doing this, I think the open sharing is probably the number one reason to use these types of solutions. You get people that are in their own niche and know specific parts of the system inside and out. That builds credibility and increased profits, but the companies are too nervous to stand behind their people.
- bonzini 3y ago
  > you're using a supported and exact version of the hypervisor and associated tools Having exact versions is not a problem (any version of RHEL guests are supported on any RHEL hosts past and future, almost). Plus Windows, ESX, Amazon and Google clouds, and a few more. Rather, the problem is having _up to date_ versions; with RHEL you can often ask the customer to reproduce on an up to date host if possible, with other distros the support machinery isn't there and you need someone to talk to at the cloud provider, so that they can debug stuff that breaks only in their environment and can't be reproduced. Otherwise you cannot guarantee the level of support that you mention. Very few cloud provider can provide that, I am not even sure that IBM's cloud made the short list.
  - XorNot 3y ago
    Isn't long term support Red Hat's thing? The ask isn't to support some random system, it's for RH to put out an official image and distro they support on cloud providers and bake the licensing costs into the hourly runtime fees. This is exactly how you consume Windows on AWS and it's a huge incentive to do it that way because it takes licences management out of consideration.
    - bonzini 3y ago
      The cloud provider is also running software, the cloud doesn't run on magic dust. Red Hat doesn't supports RHEL on your blood if they don't believe they can trust you to help supporting RHEL, the way their customers expect. The easiest way is to run RHEL as the bare metal OS but it's not the only way. > This is exactly how you consume Windows on AWS and it's a huge incentive to do it that way because it takes licences management out of consideration. It's also how you consume RHEL on AWS, GCE or Azure.
      - bonzini 3y ago
        Blood -> cloud of course.

avhception 3y ago

That's sad. And we'd have to figure out what to do with the bare metal instances and containers, too.

freedomben 3y ago

I think this sucks, but for a little bit of defense of RH on this the entire support stack is built around assuming a RHEL host (meaning you're using a supported and exact version of the hypervisor and associated tools). Adding support capabilities for a non-RHEL host would be a major task, and not one they are well equipped to do. Now that said it's a bit dumb because with most things it's not hard for support to tell your customer, "yep that's a problem in the guest" and help, or "that's a problem with the host, contact DO" or whoever. But in general, when Red Hat says something is "supported" they are guaranteeing a lot about it. They'll literally fix the code if something is wrong. There's also a culture internally of "be careful helping with something that is 'unsupported'" because customers have previously accused RH people of messing stuff up and demanding they fix it. I helped with stuff like that most of the time when I worked for RH, but I was always very clear with the customer that "this isn't Red Hat, this is me helping as a friend and fellow Linux nerd" and the rapport with the customers was always good enough that I wasn't worried.

progmetaldev 3y ago
As someone who has done this, and benefitted from others doing this, I think the open sharing is probably the number one reason to use these types of solutions. You get people that are in their own niche and know specific parts of the system inside and out. That builds credibility and increased profits, but the companies are too nervous to stand behind their people.
bonzini 3y ago
> you're using a supported and exact version of the hypervisor and associated tools Having exact versions is not a problem (any version of RHEL guests are supported on any RHEL hosts past and future, almost). Plus Windows, ESX, Amazon and Google clouds, and a few more. Rather, the problem is having _up to date_ versions; with RHEL you can often ask the customer to reproduce on an up to date host if possible, with other distros the support machinery isn't there and you need someone to talk to at the cloud provider, so that they can debug stuff that breaks only in their environment and can't be reproduced. Otherwise you cannot guarantee the level of support that you mention. Very few cloud provider can provide that, I am not even sure that IBM's cloud made the short list.
- XorNot 3y ago
  Isn't long term support Red Hat's thing? The ask isn't to support some random system, it's for RH to put out an official image and distro they support on cloud providers and bake the licensing costs into the hourly runtime fees. This is exactly how you consume Windows on AWS and it's a huge incentive to do it that way because it takes licences management out of consideration.
  - bonzini 3y ago
    The cloud provider is also running software, the cloud doesn't run on magic dust. Red Hat doesn't supports RHEL on your blood if they don't believe they can trust you to help supporting RHEL, the way their customers expect. The easiest way is to run RHEL as the bare metal OS but it's not the only way. > This is exactly how you consume Windows on AWS and it's a huge incentive to do it that way because it takes licences management out of consideration. It's also how you consume RHEL on AWS, GCE or Azure.
    - bonzini 3y ago
      Blood -> cloud of course.