Bug 1392741 - When upgrading to RHV4.0, restore database is read from the wrong location
Summary: When upgrading to RHV4.0, restore database is read from the wrong location
Keywords:
Status: CLOSED DUPLICATE of bug 1394740
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-hosted-engine-setup
Version: 4.0.4
Hardware: All
OS: Linux
unspecified
high
Target Milestone: ---
: ---
Assignee: Sandro Bonazzola
QA Contact: meital avital
URL:
Whiteboard: infra, hosted-engine
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-11-08 06:12 UTC by Marcus West
Modified: 2021-08-30 12:36 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-11-21 07:19:33 UTC
oVirt Team: Integration
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHV-43252 0 None None None 2021-08-30 12:36:28 UTC
Red Hat Knowledge Base (Solution) 2769531 0 None None None 2016-11-21 00:36:02 UTC

Description Marcus West 2016-11-08 06:12:29 UTC
## Description of problem:

I'm upgrading my HE environment from 3.6 to 4.0, and 'hosted-engine --upgrade-appliance' fails when trying to reload the database backup I have taken.

## Version-Release number of selected component (if applicable):

ovirt-hosted-engine-ha-2.0.4-1.el7ev.noarch
ovirt-hosted-engine-setup-2.0.2.2-2.el7ev.noarch
rhvh-4.0-0.20161012.0

## How reproducible:

Twice now

## Steps to Reproduce:
1. Install 3.6 environment
2. upgrade first hypervisor with 4.0 image
3. run 'hosted-engine --upgrade-appliance' as per instructions

## Actual results:

Fails with the error message:

[ INFO  ] Found an OVF for HE VM, trying to convert
[ INFO  ] Got vm.conf from OVF_STORE
[ INFO  ] Running engine-setup on the appliance
          |- FATAL: /tmp/engine_backup.tar.gz does not exist
          |- HE_APPLIANCE_ENGINE_RESTORE_FAIL

## Expected results:

The backup seems to be copied over to /root:

[root@rhevmhe1 ~]# ll /root/engine_backup.tar.gz 
-rw-r--r--. 1 root root 1097808 Nov  8 00:03 /root/engine_backup.tar.gz

It should copy it over to /tmp, or try and read it from /root

## Additional info:

To verify the ova, i had to create a temporary filesystem and use that, as upgrading RHVH leaves me with no filesystems with the required capacity (50GB)

Filesystem                                                   Size  Used Avail Use% Mounted on
/dev/mapper/rhvh_intelh5-rhvh--4.0--0.20161012.0+1           3.8G  2.9G  987M  75% /
devtmpfs                                                     5.8G     0  5.8G   0% /dev
tmpfs                                                        5.8G  4.0K  5.8G   1% /dev/shm
tmpfs                                                        5.8G   73M  5.8G   2% /run
tmpfs                                                        5.8G     0  5.8G   0% /sys/fs/cgroup
/dev/mapper/rhvh_intelh5-var                                  15G  761M   15G   5% /var
/dev/mapper/WDC_WD1001FAES-75W7A0_WD-WCATR3546032p1          976M  207M  703M  23% /boot
tmpfs                                                        1.2G     0  1.2G   0% /run/user/0
/dev/mapper/7a4132e5--f66d--4473--881a--a62de7bf3035-master  976M  1.3M  924M   1% /rhev/data-center/mnt/blockSD/7a4132e5-f66d-4473-881a-a62de7bf3035/master
/dev/mapper/rhvh_intelh5-mytmp                                55G   33M   55G   1% /var/tmp2

Comment 5 Germano Veit Michel 2016-11-08 23:55:40 UTC
If I understand this correctly:

1. Upgrade procedure asks user where the backup is in the host

eg: [host] /xyz/backup

2. We copy it to the appliace using the exact same path.

eg: [appliance] /xyz/backup

3. The restore procedure in the appliance expects the backup in a hard-coded location:

eg [appliance]  /root/backup

4. Since there is nothing copied in /root/backup, it fails. The backup was in /xyz/backup.

Comment 8 Marina Kalinin 2016-11-19 03:49:34 UTC
This might be the kcs:
https://access.redhat.com/solutions/2769531
If this bug is a duplicate of bz#1394740

Comment 9 Marcus West 2016-11-21 00:35:05 UTC
yes looks like the same issue - I will link https://access.redhat.com/solutions/2769531

Comment 10 Yaniv Kaul 2016-11-21 07:19:33 UTC

*** This bug has been marked as a duplicate of bug 1394740 ***


Note You need to log in before you can comment on or make changes to this bug.