COOKBOOK - How to add VMWare machines to Satellite 6 - Work in progress

Latest response

This document will list the method used to add VMWare virtual machine to the Satellite 6 system so that they can be patched/controlled.

First thing is to get Satellite 6 working on your environment. This is documented in "Cookbook - a basic install for patch control - WORK IN PROCESS"

After finishing that then you need the following items to complete this task.

  1. Running Satellite 6 system (check)
  2. A virtual machine on the virtual environment you are going to control. (ie. one machine to control all others)
  3. A login to the virtual machine environment ( ie user id for Satellite 6 to use for data collection).
    This login only needs Read-Only access to the VMWare servers that contain the virtual machines to be monitored/controlled.

Ok to start you need to yum install the virt-who package on the machine. The configuration file is located in:

/etc/sysconfig/virt-who

Edit this file and change the following items ( this is for VMWare virtuals otherwise you mileage may vary )

VIRTWHO_BACKGROUND=1
VIRTWHO_DEBUG=1
VIRTWHO_ESX=1

VIRTWHO_ESX_OWNER="ORG NAME" - org name from Satellite 6
VIRTWHO_ESX_ENV=Library - the base patching level
VIRTWHO_ESX_SERVER=255.255.255.255 - the IP address of the VSphere server
VIRTWHO_ESX_USERNAME="username" - this is the login id of the user that can see the ESX servers that your virtual run on
Remember on windows you must supply the windows domain as part of the username "domain\\username"
You have to use a double backslash as the first one excapes the second so that it can actually be used as a backslash
VIRTWHO_ESX_PASSWORD="password" - this is the password for the above user.

You can test the user id and password using the VMWare client to display the systems it can see.

After editing the virt-who file then you need to start the service.
service virt-who start

When you go back to Satellite 6 you need to refresh the "content hosts" screen and you should see systems with long number sequences. These should be the VMWare servers that the system finds.

To put system names on these systems you will need to look at the VMWare environment and record what virtuals are on what real servers.

Then pick one virtual to connect to Satellite 6 the command sequence to be used is:

virtual command line: use the first line supplied from the Satellite 6 "Register Content Host" screen. It looks something like this.
rpm -Uvh http://satellite.example.com/pub/katello-ca-consumer-latest.noarch.rpm
Notice that I replaced the domain name with "example". The screen is not a generic entry but an entry for your specific environment.

The second command line items is:
subscription-manager register --org="Organization" --environment="Library"
I replaced my org with "Organization" on you system it will have the organization you specified on your Satellite 6 system.

This will register your system with the Satellite system. You will have to refresh your screen to see it. Also the screen only displays 20 systems at first. If you want to see more then you need to pull down the screen and it will collect an additional 20 systems to display. If you have several hundred systems this can get to be a real pain point.

When you see your system you need to double click on the system name and it will display system info on the right side of the screen. The "Datails" tab will be displayed. On that screen should be an entry for "Virtual Host" which is the real machine that is hosting this virtual machine. If you double click on the machine name listed it will take you to the screen for that machine. In that screen you can edit the machine name to a "User usable" name.

Then select the virtual machine that you were working on and it will display the info with the "User usable" name for "Virtual Host".
There will be a tab for "Subscriptions" select the tab and the Subscriptions screen will display. The list/remove tab will be active and there should not be any subscriptions listed. Select the "Add" tab and there will be a list of the available subscriptions to be applied to the machines.
Reselect the list/remove tab and the subscription will be displayed for this machine. Also the indicator towards the top of the screen should be "GREEN" and listed as valid. So now you have a system subscribed to get patches.

Back on the command line you now need to issue this command:
subscription-manager repos
This will get the available repos list from the Satellite system. You will not need to figure out what poolid's are need for the subscriptions because the Satellite system knows what they are. You now need to edit the redhat.repo file in /etc/yum.repos.d. You need to enable the common repo as this is where the katello-agent rpm is.

After the subscription-manager command completes the issue this command:
yum repolist
I know that this can be done with any other yum command but by doing it by itself you can isolate/identify any problems at this time.

After yum has gotten the new repos then you can issue this command:
yum install katello-agent
This will install the katello-agent so that the Satellite system can display the "errata" need for this machines repo updates.

At this point you can use the yum update command and patch your machine.

Bob

Responses

Bob,

Thanks for putting this together.

I think there needs to be a little more clarity around the components involved. As it stands, it's difficult to follow which machine/system you are modifying at each step.

Can I suggest defining each system's name at the start of the cookbook and then referencing them by name throughout the document?

Is my understanding correct that even though you have a virtual machine proxy in place retrieving details from ESX, the registration of these ESX guests is still manual following this procedure?

Can someone explain why I would choose this option over registering every VM directly with the Satellite server during build? this allows the same process to be used for both physical and virtual machines.

Does this solution work for multiple clusters / vcenters through the one proxy?

PixelDrift - Thank you for the input on changes need to this document. The basic assumption for the article: I have never used Satellite in any form before and am trying to get it running just to get patching running. Using a basic method is the fastest way to explain what I have learned in the last 30 days. I have spent over 50 hours on the phone resolving problems with support to make the system operational. Which I have just done. I wanted to get my basic understanding down on paper so that the knowledge would not be lost. I will be correcting the document based upon you input and I think that you are correct as to those items. BUT I have not gotten past the basic stage of usage of the product.

Now it has always been my belief that you start from the simple and work up to the complex. You will be more successful than any other method. But then again I have only been using REDHAT products since 1994 and RedHat 4.2 so I don't know much about it.
Yes I started from a difficult basis. I started from RedHat 7 and Satellite 6. Not a simple solution but why start from old stuff and have to upgrade 6 months later when I should be able to start at the latest level and be successful.

Please understand that what I spend my time on I want to be successful doing. So as a first pass the basic parts are there. And yes thank you for the input as that needs to be done and I will correct it as we go.

Bob - edited to remove incorrect flame stupidity.

Hi Rob,

Thanks for the response.

Unfortunately I don't have access to Satellite 6, so my questions were genuine (although they may appear facetious) as I haven't been exposed to Red Hat recommendations regarding Satellite 6 configuration. The questions were in general to the Red Hat employees on the board and weren't intended as a criticism of your effort spent.

I agree that you shouldn't be required to write documents such as this, and I also believe that with a few of the recent product releases that the documentation could be better. I'm sure if the documentation was perfect for every situation I wouldn't have earned enough points on the community forum to become 'guru' (please ignore the title). In this case however, patching machines would be a primary objective of most use cases, so it should definitely be covered in great detail in the documentation.

The reason for my suggestions regarding clarity is that other community members (and quite likely myself) will use this post as a resource in future so it's best to get the information from you while it's fresh in your mind.

Thanks again for putting it together.

Just to clarify, Bob, in case there was a misunderstanding - PixelDrift is a "Community Leader" on this forum, not a Red Hat employee - he's an experienced volunteer that helps out here. Red Hat associates have a red badge below their name, like the one you can see on mine to the left.

It sounds like you've been frustrated by the product documentation though, and any specific feedback you can provide will definitely be seen by the documentation teams.

/FLAME ON/
PixelDrift WHY did I have to write this document? You work for support and are a guru on this board. Why did you not write it and the documents that are supplied are CRAP. For a newbee just cumming upon this product and being required to use this product by my management as it IS the best solution for my problem. The documentation is just that - CRAP. Sorry for being so basic about it but it is.
YES - just start the basic install document with a description of a multiple site/country/universe solution to a problem when 99% of users just what to patch their boxes at first. What a brilliant solution to the problem. SORRY just my level of frustration coming out.
/FLAME OFF/

Hi Bob,

I have a feeling this criticism was meant more for the Red Hat documentation team rather than at PixelDrift. And as a representative of the Red Hat documentation team, I share some of the blame. Having said, my fellow team mates and I are more than willing to improve our documentation in whatever way possible. One of the things we want to do especially is to try and align our documentation with more real world scenarios.

I really appreciate what you've done here and in the patch control thread. These are examples of real world use cases that we want to develop documentation around.

What I'll do to kick things off is to start a seperate thread and get some discussion going on the kinds of environments people have and how they use Satellite to manage those environments. That way we can develop some more documentation around these situations.

Dan

EDIT: Started a discussion here: https://access.redhat.com/discussions/1275993

PixelDrift - Thank you for the reply. I am going to go back and make another pass at the documentation so that the interaction between Satellite and Target machine are clearer. So about sounding upset but I have had to put to many hours into resolving something that should be dead simple. Now if we were talking Puppet and other parts it is a very different matter. I have purchased 7 books on Puppet because I was looking at using it before I had to deal with Satellite 6. So there will be many more posting about how to get much more out of the Satellite Product. I also do not envy any users that have to upgrade to Satellite 6 as that will be a non-trivial matter. Again thank you for the response.

Bob

I agree that the Satellite 6 documentation is very poor. The focus of the documentation seems to revolve around how it leverage's opensource products, and how amazing the features are (like Oraganisations and Locations ). These contributions and https://access.redhat.com/solutions/1201913 seem to be the most useful so far.

Get back to the basics:
1. Explain how to provision and register existing hosts properly. Is there Cobbler buildiso anymore?
2. Explain how to patch hosts (initiated from client or server). What is the architecture involved here? No/little mention of katello agent and goferd.
3. Explain how to apply config management to hosts via puppet.

Why else do customers buy Satellite, if not to do the above three things? The documentation should clearly explain the architecture and run through 'scenarios' revolving around the three main things we use Satellite for.

Keep up the work Robert.

I agree with this. I feel the same about the RHEL 7 documentation, a lot of it reads like shopping lists, rather than objective based documentation. eg.

The widget is red, it has a brim, it is round.
vs.
This is a red hat, it can be used to protect your bald spot from the sun and impress fellow sysadmins in the workplace.

I am hoping it is because we are moving from mature (years) RHEL 6 documentation to immature RHEL 7 documentation.

Hi MRSS Group,

Thanks for the feedback and advice. I can mention that more documentation on provisioning is on its way.

I'll also share your feedback with the documentation team. I know they're always looking for ways to improve the Sat 6 documentation.

Dan

Dan--

Let me add to the constructive criticism (and hopefully in a good way).

I too have been struggling with Satellite 6.0 since the day it was released (actually, before that--I did use the Public Beta as well, at least up to the point where some show-stopping issues blocked me).

I agree with Bob T. that it would be nice if the frequent (and necessary!) doc updates were made a little more visible. Maybe start with an announcement here or in the Satellite 6 blog? In the past, I always used downloaded PDF versions of the docs; I like a good PDF reader better than giant, sprawling web pages/sites. But that just doesn't work with a doc revised as often as the Satellite 6.0 manuals.

Second...the User Guide. As a complete book, I find it...poor. It seems like more of a Reference Guide than a User Guide (walking through menu-by-menu, "to create a widget, click 'create widget' ... to delete a widget, select it and click the 'delete' button... to create a turboencabulator, click the 'turboencabulator' menu then 'add new' button...". But absolutely minimal synthesis of how all these complex parts relate to each other and are supposed to work together.

It gets especially bad with Puppet integration--I still haven't figured out how 'Puppet Environments' work, because they behave differently depending on whether they were created via the menu or as a side-effect of publishing Content Views. It seems like the "Content" menu and "Configure" menu are two entirely different projects only somewhat loosely bolted together at this point.

Let me close with a good example--outside of the official documentations "Guides", there was a whitepaper-type thing released as a KB article called "Red Hat Satellite 6.0 Core SOE". That document is an excellent start on what I think the Satellite 6.0 User Guide should be. I say start because it only covers 1 scenario, where users like Bob & myself need different cases (mostly involving patching or managing existing systems, not provisioning new). But it does tie together many pieces, in the order they need to be done (including an explicit warning that some of the earlier steps don't seem to be leading in a useful direction, but are absolutely necessary to the end result).

Another excellent feature of that doc is the inclusion of the correct 'hammer' CLI commands for every set of GUI steps given. That is fantastic! Much better than User Guide chapter 14, which IIRC can be accurately summarized as "read the help screens!", and is utterly un-helpful in describing the constraints & pre-requisites to actually use some of the hammer CLI commands--like "reboot", which exists, but doesn't work for my hosts...and doesn't say why. I have some fairly obvious guesses, but I shouldn't have to guess--that's what I read documentation for!

Thank you James. You pointed out an excellent PDF document available here: https://access.redhat.com/articles/1169613

That document is exactly what the Satellite 6 documentation should look like.

Thanks for pointing it out to me.

Hi James,

You've made some very fair criticisms and I appreciate you taking the time to tell us. I especially like the idea of posting doc updates to this forum, which is something either I or someone from the Satellite docs team will do.

I understand what you mean about the User Guide. One thing we're aiming to do in the future is develop more scenario-based documentation, starting with provisioning scenarios. Expect this documentation to be released in the near future.

Good point about the CLI instructions too. I'll pass this idea on to the Satellite docs team. At the very least, it would be good to have a demonstration of using the CLI to control your environment.

Thanks again for the feedback. Please post any other ideas you have to this forum. I'll be watching closely.

As mentioned by the OP, after the ESX hosts are added to Satellite by virt-who, the hosts show up with their UUID instead of their hostname. To find out what host name is which, browse to this URL:

https:///mob/?moid=ha-host&doPath=hardware.systemInfo

Log in with the root account. A page will be displayed which shows the UUID. You can now match up the UUID with the hostname.

Pardon my silly questions: while I'm (too) familiar with vSphere, we haven't horsed it to Satellite. So, I'm confused by:

VIRTWHO_ESX_OWNER="ORG NAME" - org name from Satellite 6
VIRTWHO_ESX_ENV=Library - the base patching level
VIRTWHO_ESX_SERVER=255.255.255.255 - the IP address of the VSphere server

Safe to assume that this refers to the vCenter server?

VIRTWHO_ESX_USERNAME="username" - this is the login id of the user that can see the ESX servers that your virtual run on
Remember on windows you must supply the windows domain as part of the username "domain\\username"
You have to use a double backslash as the first one excapes the second so that it can actually be used as a backslash
VIRTWHO_ESX_PASSWORD="password" - this is the password for the above user.

Assuming all of the "ESX" tokens refer to vCenter and not actually individual ESX hosts (misleading var-name), this would presumably be a vCenter service account that's been delegated adequate permissions to the entire vSphere inventory needed by Satellite? If so, you might want to pull in a reference to a document that enumerates each and every permission-object that needs to be set and the specific, minimum privilege that needs to be granted. Most of the environments I've worked in, service accounts used by orchestrators, backup products and the like are granted absolutely the least amount of privileges that can be delegated to the role.

Also with respect to vCenter, this is presumably the credentials to the management UI and not the OS/appliance that hosts the vCenter service, correct?

If the ESX var-names are referring to the actual ESXi hosts, then you're apt to run into problems with vSphere 5.5 and above. Your vSphere admins are going to be a bit peevish about having to have "SSH enabled" alerts all over their dashboards.

Really good and helpful article that saves me lot of times.
Why hasn't RH done anything since 1 December ? 3 months + seems to be a quit long enough time to get some step by step things done right ?
Do you really want us to use Sat 6 ?

This is no longer acurate for newer versions of RHEL and virt-who

Thanks a bunch!

It looks like the way you configured it is considered deprecated now as documentation advises to use configuration file in /etc/virt-who.d/, however, your instructions still work. I managed to get my VMWare servers listed under the "Content Hosts" in Katello 3.1 (on RHEL 7.2).

Close

Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.