[QUESTION] How does the RHUI Infrastructure and RedHat licensing work?

[imduffy15]

Hi All,

I'm trying to develop an understanding for how metered RHEL is working on Azure.

I see that if walinuxagent detects its running RHEL it goes ahead and executes the following function https://github.com/Azure/azure-linux-extensions/blob/master/Common/WALinuxAgent-2.0.16/waagent#L2891

That function appears to execute a script which is located at http://rhuirpm.blob.core.windows.net/script/install-rhui-rpm.sh additionally, it downloads a tar that contains an RPM http://rhuirpm.blob.core.windows.net/script/rhui.tar.gz

Executing that script and running that RPM results in the rhui-lb yum plugin being installed, the RHUI entitlement keys being installed and the yum repos configured.

The entitlement keys do not seem to be unique per VM, which is interesting..... If I upload my own custom RedHat image, is WaLinuxAgent going to kick off, configure all this stuff and suddenly I'll be consuming RedHat packages for free form the Azure RHUI infrastructure?

How does the Azure Platform know when and when not to charge for these instances? especially in the case of a custom image or a image that started off as redhat on the market place but was since captured and redeployed.

[imduffy15]

Additionally, what happens if a RHEL VM isn't provided with an internet gateway and is unable to reach all those resources?

[colemickens]

Hi @imduffy15,

I'm looking into these questions. Can you help me understand how you found the URL for install-rhui-rpm.sh? I don't see it in the waagent code you linked to. And similarly, how you found the URL for the bundle of RPMs?

[imduffy15]

@colemickens There's a RPM available within the repos called PrepareRhel (or something like that, going based of memory). If you expand it, it downloads and extracts the install-rhui-rpm.sh script to /tmp.

[BorisB2015]

Hi @imduffy15,

With Azure’s RHEL Pay-As-You-Go (PAYG) offering, it is the customer’s responsibility to abide by the license terms. We’re continually improving our mechanisms to detect and deter fraudulent use for all Azure resources, including those of our partners.

To answer your question about what you are getting charged for and when. If you start with RHEL Pays-As-You-Go image (which is what you find on the marketplace), the platform keeps track of it being a paid image and also carries that metadata when you take snapshots and provision new VMs from the snapshots. You will be charged RHEL premium in addition to Azure resources for the VMs which are originating from RHEL PAYG images. Those VMs are fully supported and allowed to use Azure RHUI.

We currently do not support conversion of PAYG to Bring-Your-Own-License (BYOL) VM types and vice versa.

To use Azure RHUI on an Azure RHEL VM the license terms require you to use a paid image. If you are starting with BYOL image (assuming you have purchased your subscription from Red Hat or their reseller directly), you will NOT be charged above general “Linux” prices and you will need to register your VM with Red Hat customer portal or Red Hat Satellite to get updates. We currently do not support registering (or using) Azure RHUI on RHEL BYOL VMs even if they run in Azure. As I said there is no conversion between BYOL and PAYG as of today so you should never be charged RHEL premium on BYOL VM.

As an example, you can use RHEL PAYG for development purposes and be current on updates via Azure RHUI, fully supported, etc. and may choose BYOL images for production purposes if this is beneficial for you. Note that you can start and stop VMs as needed and you are charged on per minute increments.

Please let me know if this warrants an offline conversation.

Thanks, Boris.

[imduffy15]

Hi Boris,

Thank you for the information.

If you start with RHEL Pays-As-You-Go image (which is what you find on the marketplace), the platform keeps track of it being a paid image and also carries that metadata when you take snapshots and provision new VMs from the snapshots

Can you prove this out for me a little more?

I've followed the process at https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-linux-capture-image/ for capturing a RHEL6 VM that was created using the marketplace. After deploying the capture image as documented, I lost the "Red Hat Customer Portal" option in my side bar. Which to me, suggests that this instances is no longer classified as a Red Hat virtual machine, is no longer under support and no longer under metered billing.

I'm lacking to understand, how the process for capturing a VM would maintain billing/instance metadata, as the capture is just effectively a clone of the VHD?

Given the above it raises the question for me - How do you identify a VHD that was created by cloning a RHEL marketplace VM versus one I uploaded manually?

The captured VM can still interact with RHUI just fine, this is because the repo information and entitlement keys have been kept. They appear to be the same across all azure RHEL6 VMs (or atleast in the northeurope region). From what I can see they are baked into the image using the RPM in the above linked tar.gz. If one was to install this same RPM on a custom image or even a centos image, they would start consuming packages from RHUI.

We currently do not support conversion of PAYG to Bring-Your-Own-License (BYOL) VM types and vice versa.

Thank you for confirming this as a definite. This is a fairly large drawback, given a scenario where one wants to follow security measures outlined benchmarks like CIS and NIST one of the most basic items is separate partitions. Beyond uploading a custom image I don't see any way this is achievable.

A competing cloud provider doesn't officially support custom images under metered billing, however their some workarounds as discussed here https://access.redhat.com/discussions/1285693 and automated over here https://github.com/ferricoxide/AMIgen6 Their deployment models are RHEL are a little bit different. Its genuine in terms of you are paying the license but not stood by the vendor - it could break tomorrow (probably won't though).

The only approach I see going forward would be to deploy RedHat satellite across each region and define some sort of an automation process for registration and deregistration of VMs. This is a fairly large overhead in terms of deployment effort, costs, maintenance, time, etc.

https://github.com/Azure/azure-linux-extensions/blob/master/Common/WALinuxAgent-2.0.16/waagent#L2891

The initial bit of code in the 2.0.16 agent I linked in my opening message and above is a little confusing within this context.

So its running a script within /tmp, how does that script get into /tmp? /tmp is wiped on reboot so it should really shouldn't exist as a baked entity, rather it would suggest there's some provision stage which puts it there? such as an installation of the PrepareRHUI.noarch package? https://gist.github.com/imduffy15/c53e9b1ba4f05f700dcfda4c5689f683 what triggers this to occur?

From what I understand, the LinuxDistro variable is set via lib pythons platform library: https://hg.python.org/cpython/file/2.7/Lib/platform.py, from what I understand it detects the existence of a redhat running system by evaluating /etc/redhat-release. Given such logic, the agent would attempt to run that same script on a custom uploaded RHEL VHD, I'm assuming it would fail due to /tmp/install-rhui-rpm.sh not existing.... but lets say that script did exist, wouldn't the system now be configured for communicating with RHUI?

None of this is for the purposes of negative intent, just trying to find the best and easiest way to run RHEL on Azure.

[BorisB2015]

Hi Ian,

Sorry for the delay in replying on this. A brief response and then we can follow up offline for additional details.

Billing metadata of the image goes with the VHD and preserved through snapshots, so the scenario when you started with a metered (PAYG) image, modified it for your needs, took a snapshot and provisioned new VMs from it should work as metered image.

The reason the link "Red Hat Customer Portal" disappears in this case is because in the current portal implementation it is based on the image publisher ("Red Hat") and once you take the snapshot you become the "publisher". It is a known ask for us to improve this (ensure portal is capable of displaying this link based on the billing metadata and not the publisher) and make it work in other scenarios.

One way to see that your VMs are still metered is to look at RateCard API.

A couple of links you mentioned refer to LVM config on the VM. While we do support LVM configuring it on OS disk is generally not recommended (but it does not mean impossible as long as you understand effects on possible recovery scenarios). This part I'd like to discuss offline and then we could post a more general update on this thread for use of others. I will ask @transponstergrl to introduce us offline. I believe we can make this work and you should be able to have RHEL metered image configured per CIS/NIST standards.

Thanks, Boris.

[imduffy15]

Borris Thank you very much for these answers! Our team has been working with Microsoft and RedHat looking for a means to do such a thing for just over 4 weeks now.

Billing metadata of the image goes with the VHD and preserved through snapshots

So lets say I take that VHD offline via the download function, modify it, and re-upload, does the license hold? If so it sounds like this could be possible workaround.

The reason the link "Red Hat Customer Portal" disappears in this case is because in the current portal implementation it is based on the image publisher ("Red Hat") and once you take the snapshot you become the "publisher". It is a known ask for us to improve this (ensure portal is capable of displaying this link based on the billing metadata and not the publisher) and make it work in other scenarios.

Thank you for understanding the confusion around this - I really appreciate it.

I believe we can make this work and you should be able to have RHEL metered image configured per CIS/NIST standards.

Thanks again for all your support on this Boris, if this is an outcome we can achieve it would be an absolutely fantastic result! I look forward to working with you.

[BorisB2015]

For the scenario you describe - if you are paying for the modified image its RHEL premium - you are in compliance. Platform knows this from billing metadata. Because we do not publicly disclose how this works - there is no easy way for you to check after the modifications except to check for actual billing usage from RateCard API for the VM provisioned from such image (it may have a delay before the data shows up - I don't recall how long). In most cases this works as expected.

Please contact me at (BorisB at Microsoft).

Thanks, Boris.

[hglkrijger]

Seems like this conversation switched to email, closing this issue.