Ensuring compliance with multiple Red Hat Enterprise Linux for Virtual Datacenters, Standard and Red Hat Enterprise Linux for Virtual Datacenters, Premium subscriptions under the same account

Solution Verified - Updated

Environment

  • Red Hat Satellite 6.x
  • Hypervisors registered to Red Hat Satellite 6.x

Issue

  • Do the VMs running on a particular hypervisor inherit the same service level if the hypervisor's Service Level attribute is set to Premium, Standard, or Self Support) in Red Hat Satellite 6.x?

Resolution

  • The VMs running on a specific hypervisor do not inherit the Service Level from the hypervisor. From Red Hat Satellite's perspective, the hypervisor and its VMs are separate hosts. Therefore, there is no inheritance of system purpose attributes (including the Service Level attribute) from the hypervisor.

  • The following RFE This content is not included.automate setting system purpose on hypervisors so that guests can inherit it has been raised to add a mechanism that allows the Service Level attribute to propagate from the hypervisors to the VMs running on it.

  • To ensure that the VMs running on a hypervisor match the same service level as the hypervisor, the following applies:

    • If the virtualization infrastructure is set up with standalone (i.e., non-clustered hypervisors), make sure the VMs are running on that specific hypervisor all the time. And if, for any reason, they are to be migrated to a different hypervisor, the target hypervisor will need to have the same service level as the source hypervisor.

    • If the virtualization infrastructure is set up with clustered hypervisors, there are 2 possible ways to ensure that VMs have matching service levels as the hypervisors they are running on:

      1. Cluster separation:

        Here, the Premium vs. Standard VDC subscriptions are treated as follows:

        • Premium VDC subscriptions are dedicated for hypervisors running production VMs, and highly critical non-production VMs.

        • Standard VDC subscriptions are dedicate for hypervisors running less critical non-production VMs.

        Based on this classification, separate clusters of hypervisors need to be built:

        • Clusters of hypervisors running production and highly critical non-production VMs:
          The total number of sockets consumed by hypervisors in these clusters must not exceed the total number sockets provided by the active Premium VDC subscriptions you have under your account.

        • Clusters of hypervisors running less critical non-production VMs:
          The total number of sockets consumed by hypervisors in these clusters must not exceed the total number of sockets provided by the active Standard VDC subscriptions you have under your account.

      2. Using affinity/anti-affinity rules:

        This approach can be utilized to strictly enforce that production and highly critical non-production RHEL VMs only run on the Premium-licensed hypervisors, and the less critical non-production RHEL VMs only run on Standard-licensed hypervisors.

  • Please refer to Red Hat's Production Support Terms of Service for details on how the Premium SLA differs from the Standard SLA.

  • Please refer to Are additional VDC Subscriptions required for Hypervisors with more than 2-sockets? for further details on dealing with hypervisors with more than 2 CPU sockets.

For more KB articles/solutions related to Virt-who and Virtual Datacenter (VDC) Subscriptions Issues, please refer to the Consolidated Troubleshooting Article for Virt-who and Virtual Datacenter (VDC) Subscriptions Issues

SBR
Product(s)

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.