## Description of problem: I have an internal RHV environment that does not connect to the internet. When installing a new HE environment (or adding a new HE host), I am asked the following: [ ERROR ] No engine appliance image is available on your system. The oVirt engine appliance is now required to deploy hosted-engine. You could get oVirt engine appliance installing ovirt-engine-appliance rpm. Do you want to install ovirt-engine-appliance rpm? (Yes, No) [Yes]: Answering 'no' causes the install to fail. Answering 'yes' will try to install rhvm-appliance, which will fail. ## Version-Release number of selected component (if applicable): ovirt-host-deploy-1.6.5-1.el7ev.noarch ovirt-hosted-engine-setup-2.1.0.6-1.el7ev.noarch ## How reproducible: Always ## Steps to Reproduce: 1. Install RHEL7 (on a system without internet access) 2. run 'hosted-engine --deploy' ## Actual results: Deploy either fails, or tries to install rpm package, which will never succeed. ## Expected results: Allow deploy to proceed. Later, the installer prompts if you want to directly specify an ova file, which is fine. However currently the rpm needs be installed anyway, so the option is not so useful. ## Additional info: There are two situations where this is a problem: 1. Adding a new HE host to an existing environment - there is no need to download a 1.8G appliance RPM, so why enforce this? 2. New deploy - it's easier for customers to download appliance file in ova format, as that is what we offer on the Portal: https://access.redhat.com/downloads/content/150/ver=4.1/rhel---7/4.1/x86_64/product-software If we can't make changes to the deploy script, then we need to offer the rpm file on the Download page, or make it easier to access. I have also tried installing cockpit and doing the deploy that way - same issue.
This is the desired behavior for hosted engine in 4.1 and later. The only supported way to install Hosted Engine is by using the appliance. Any other way was deprecated in 4.0 and has been removed in 4.1. I'm going to close this as not a bug.
(In reply to Sandro Bonazzola from comment #3) > This is the desired behavior for hosted engine in 4.1 and later. > The only supported way to install Hosted Engine is by using the appliance. > Any other way was deprecated in 4.0 and has been removed in 4.1. > > I'm going to close this as not a bug. Hi Sandro, This doesn't sound right or logical. 1. Installer only accepts the appliance RPM. Answering 'no', as explained in comment #0, to download the RPM fails the install process. 2. We only offer the OVA to download in the Customer Portal, not the rpm. (offline customers?) 3. If one answers 'yes' to download, later the he-setup asks if user wants to use the appliance or provide a path to the OVA. Shouldn't this be removed if we enforce the usage of the rpm? 4. What does "we only support the appliance" mean? We seem to be enforcing the rpm, but the OVA is also "the appliance". It looks like at the very least we should improve the process for offline users, perhaps providing the .rpm instead of the .ova on https://access.redhat.com/downloads/content/150/ver=4.1/rhel---7/4.1/x86_64/product-software. I'm opening the BZ again for further assessment. This is about providing a way to deploy HE without internet access in the Hosts and without having to open a support case.
Moving to release engineering for handling the portal changes
What is needed here? should we add the rhvm-appliance rpm to the ISOs download page? https://access.redhat.com/downloads/content/150/ver=4.1/rhel---7/4.1/x86_64/product-software Can PM give their input?
Another option, rhvm-appliance rpm is available to download from rhv-mgmt-agents repo on Unified Download page: https://access.redhat.com/downloads/content/150/ver=4/rhel---7/4/x86_64/packages
*** Bug 1466959 has been marked as a duplicate of this bug. ***
I don't see how this issue considered as a bug? This system behavior works by design, the documentation "https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.1/html/self-hosted_engine_guide/chap-deploying_self-hosted_engine#Deploying_Self-Hosted_Engine_on_RHEL" clearly states that: "2.1. Initiating Self-Hosted Engine Deployment on Red Hat Enterprise Linux Hosts Procedure 2.1. Installing the Self-Hosted Engine: 2.1.1. Installing the Self-Hosted Engine Packages Ensure the host is registered and subscribed to the required entitlements. See Subscribing to the Required Entitlements in the Installation Guide for more information. 2.Optionally install the RHV-M Virtual Appliance package for the Manager virtual machine installation. Alternatively, the script will prompt you to download it during deployment. # yum install rhvm-appliance You can install the RHV-M Virtual Appliance manually before deployment by installing the rhvm-appliance package. Alternatively, the script or Cockpit user interface will download it for you during deployment. Other methods of installing the Manager virtual machine operating system are not supported." "2.2. Initiating Self-Hosted Engine Deployment on Red Hat Virtualization Host 2.3. DEPLOYING THE SELF-HOSTED ENGINE 2.Downloading the RHV-M Virtual Appliance If you have not manually downloaded the RHV-M Virtual Appliance, you can download and install it during deployment. Select Yes to download the appliance." User should either manually yum install rhv-appliance prior to hosted-engine installation (2) and it's later deployment or to have internet access to RHN channels to get appliance downloaded and installed during hosted-engine deployment (2.1.1.). #1. Adding a new HE host to an existing environment - there is no need to #download a 1.8G appliance RPM, so why enforce this? To add additional ha-host you really don't need to download rhvm-appliance and its not enforced, you should add additional ha-host from UI and it will be added without installing or downloading of rhvm-appliance package. #2. New deploy - it's easier for customers to download appliance file in ova #format, as that is what we offer on the Portal: Working with images directly is not making deployment process easier, customers making mistakes when downloading images in to different paths on their hosts, they're not checking for if there is enough free space on disk, process not automated and takes much more time vs. automated rpm download from RHN channel. You also will have to manually download rhevm-appliance for upgrade flow 3.6->4.0 and rhvm-appliance for clean fresh 4.1 deployment, while these are automated already, while being executed with current code.
Please provide your input based on https://bugzilla.redhat.com/show_bug.cgi?id=1461251#c9.
Hello, I completely agree with Marcus and Germano. Today I had a customer who was very confused as well. What about an offline deployment? Marcus has created KCS: https://access.redhat.com/solutions/3080991 but is it a nice looking solution? IMO it is definitely not. Actually, the biggest problem is that we have changed our approach to RHV appliance but it is not enough emphasized in the documentation: https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.1/html-single/self-hosted_engine_guide/#Deploying_Self-Hosted_Engine <quote> 2. Downloading the RHV-M Virtual Appliance If you have not manually downloaded the RHV-M Virtual Appliance, you can download and install it during deployment. Select Yes to download the appliance." </quote> There are many users who got used to OVA file and they don't even think about rpm. "manually downloaded the RHV-M Virtual Appliance" means for them just OVA file.
Hi Nikolai > To add additional ha-host you really don't need to download rhvm-appliance and its not enforced, you should add additional ha-host from UI and it will be added without installing or downloading of rhvm-appliance package. Agreed - I forgot this is the recommended way now. If using rpm is now the preferred way (and I agree with this), then probably no code changes are required. However we still need to. 1. Better documentation, so that it's obvious that now, you need to download the rpm manually (offline installation), where as before, you could use the ova file. 2. Make it easier to download the rpm (ie, provide it from the product download page)
(In reply to Marcus West from comment #12) > Hi Nikolai > > > To add additional ha-host you really don't need to download rhvm-appliance and its not enforced, you should add additional ha-host from UI and it will be added without installing or downloading of rhvm-appliance package. > > Agreed - I forgot this is the recommended way now. > > If using rpm is now the preferred way (and I agree with this), then probably > no code changes are required. However we still need to. " Other methods of installing the Manager virtual machine operating system are not supported." > > 1. Better documentation, so that it's obvious that now, you need to download > the rpm manually (offline installation), where as before, you could use the > ova file. Again, ova is not supported and its documented: - "2.Optionally install the RHV-M Virtual Appliance package for the Manager virtual machine installation. Alternatively, the script will prompt you to download it during deployment. # yum install rhvm-appliance" > > 2. Make it easier to download the rpm (ie, provide it from the product > download page) The prerequisites are to have a working registered environment with all hosts subscribed to RHN channels are already clearly documented and if you don't have RHN connection, then it is obvious that appliance and other updates won't be downloaded: - "2.1.1. Installing the Self-Hosted Engine Packages Ensure the host is registered and subscribed to the required entitlements. See Subscribing to the Required Entitlements in the Installation Guide for more information.". The only thing I may think of in this case is about refining Customer Portal and refining documentation for offline deployments. (In reply to Olimp Bockowski from comment #11) > Hello, > > I completely agree with Marcus and Germano. Today I had a customer who was > very confused as well. > What about an offline deployment? > Marcus has created KCS: > https://access.redhat.com/solutions/3080991 > but is it a nice looking solution? IMO it is definitely not. > Actually, the biggest problem is that we have changed our approach to RHV > appliance but it is not enough emphasized in the documentation: > > https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.1/ > html-single/self-hosted_engine_guide/#Deploying_Self-Hosted_Engine > > <quote> > 2. Downloading the RHV-M Virtual Appliance "2.Optionally install the RHV-M Virtual Appliance package for the Manager virtual machine installation. Alternatively, the script will prompt you to download it during deployment. # yum install rhvm-appliance" "yum install rhvm-appliance" can't be an ova image, so I see that this is properly documented. > > If you have not manually downloaded the RHV-M Virtual Appliance, you can > download and install it during deployment. Select Yes to download the > appliance." > </quote> > > There are many users who got used to OVA file and they don't even think > about rpm. "manually downloaded the RHV-M Virtual Appliance" means for them > just OVA file. This was properly documented as I already mentioned: " Other methods of installing the Manager virtual machine operating system are not supported."
I'm not sure how this bug changed so much and why some are making changes to our support statement without consulting PM. We created a regression when we removed the option to install HE offline and use OVA. This was a side effect of adding the RPM download. I expect that to be fixed and allow users to say 'no' on RPM download in setup.
*** Bug 1470576 has been marked as a duplicate of this bug. ***
(In reply to Yaniv Lavi from comment #24) > I'm not sure how this bug changed so much and why some are making changes to > our support statement without consulting PM. > We created a regression when we removed the option to install HE offline and > use OVA. This was a side effect of adding the RPM download. > I expect that to be fixed and allow users to say 'no' on RPM download in > setup. Hi Yaniv, Just to confirm: so contrary to what was stated in comment #15 we will continue supporting using OVA for SHE deployment? Is this regression going to be tracked on this bug?
(In reply to Germano Veit Michel from comment #26) > (In reply to Yaniv Lavi from comment #24) > > I'm not sure how this bug changed so much and why some are making changes to > > our support statement without consulting PM. > > We created a regression when we removed the option to install HE offline and > > use OVA. This was a side effect of adding the RPM download. > > I expect that to be fixed and allow users to say 'no' on RPM download in > > setup. > > Hi Yaniv, > > Just to confirm: so contrary to what was stated in comment #15 we will > continue supporting using OVA for SHE deployment? Is this regression going > to be tracked on this bug? Yes and I hope we can fix this in the coming z stream.
When the user answers 'No' (to install ovirt-engine-appliance), do we want to present a link to the appliance RPM (from the customer portal / oVirt site) or request for a path to the appliance's OVA file? I just think that if the issue is about offline deployment, then the user will have to download manually the OVA as it can download manually the RPM. If he downloads the RPM and install it manually, no (major) code change will be required (except adding messaging and links )
(In reply to Ido Rosenzwig from comment #30) > When the user answers 'No' (to install ovirt-engine-appliance), do we want > to present a link to the appliance RPM (from the customer portal / oVirt > site) or request for a path to the appliance's OVA file? Path to OVA same as before. We should skip the version checking with info message that they were skipped.
Forth to https://bugzilla.redhat.com/show_bug.cgi?id=1481095#c34 and because its working fine also on upstream ovirt-hosted-engine-setup-2.2.0-0.0.master.20170831115238.git6d9b02e.el7.centos.noarch, moving to verified.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2018:1471
BZ<2>Jira Resync