Hi Brian, On 28.01.2021 23:38, Brian (bex) Exelbierd wrote: >> As I understand from the Red Hat blog article "New Year, new Red Hat >> Enterprise Linux programs: Easier ways to access RHEL" I am limited >> to only 16 no-cost RHEL instances. Limit 16 instances means >> bare metal servers and KVM virtual machines, right? > > In general yes, containers, as mentioned below are a bit ambiguous > without some definition. > >> But what about systemd-nspawn OS-level virtualization containers? >> To be able run "yum update" inside systemd-nspawn containers >> I need to activate Red Hat subscription inside each container too??? > RHEL UBI containers when run on an entitled RHEL host do not need to > be separately entitled and do not count toward the 16 entitlements. > This is part of the set of "super powers" RHEL UBI gets when run on > RHEL. Situation with RHEL UBI is clear, and I don't ask about them. My question is exclusively about systemd-nspawn containers. https://www.freedesktop.org/software/systemd/man/systemd-nspawn.html systemd-nspawn containers provided in RHEL by systemd-container package. > If you run the registration inside of the container, > that will count toward your 16 entitlements. Yes, I understand what if I run the registration inside of the container, that will count toward my 16 entitlements. My question is this: Is it legal to use RHEL inside systemd-nspawn containers without registration and without activation subscription inside the container? Do I need to start the registration process inside each container, or will the "yum update" command inside the container work without it? >> What is about running in the one bare metal RHEL server virtual machines >> with different subscription owners? For example, run in production on >> one bare metal server 16 VMs with subscription owner Alice, and 16 VMs >> with subscription owner Bob, and 16 VMs with subscription owner Carl, >> and so on. Are such configurations legal and allowed or not? I didn't >> find any limitations on the blog article, but for sure and for future I >> need a clean and unambiguous answer from Red Hat. >> >> If such configurations are allowed - this is a legal workaround for a >> limit of 16 no-cont RHEL instances. For example, a small company, with >> 50 employees can absolutely legally have free and no-cost 800 RHEL >> servers in self-support mode. Company with 100 employees can have 1600 >> free no-cost RHEL servers in self-support mode and so on. > No. The Individual Developer Subscriptions do not accrue > to a company. Companies do not get to use this program. Are you talking about the announcement on 1 February "No-cost RHEL for small production workloads" ? Surprise! Developer Subscriptions allowed to use for production workloads only by individuals, and totally forbidden to use by companies? : We’re addressing this by expanding the terms of the Red Hat Developer : program so that the Individual Developer subscription for RHEL can be : used in production for up to 16 systems. That’s exactly what it sounds : like: for small production use cases, this is no-cost, self-supported : RHEL. "can be used in production for up to 16 systems" - I didn't find here forbid to use by companies. > Red Hat believes that in the situation you describe a company would > be best served by having a conversation with a commercial provider > to find a good fit for this workload. Obviously we'd like that > to be with us about RHEL, but we understand that other options > exist in the market. Conversation about what? no-cost RHEL as I understand is forbidden to use by companies. 350 USD/year RHEL is forbidden to use for virtual machines. 800 USD/year RHEL is too expensive for each bare metal / VM / container. Website hosting is low-margin businesses, it is unreal to pay 800 USD/year for each virtual machine/container. One hosting server can have several dozen or even several hundred of virtual machines or systemd-nspawn containers. As I understand, there are only two available options for me: 1) Migrate to Oracle Linux, Alma Linux, Rocky Linux. 2) Migrate to Ubuntu / Debian / some other distro. -- Best regards, Gena