## 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
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.
This might be the kcs: https://access.redhat.com/solutions/2769531 If this bug is a duplicate of bz#1394740
yes looks like the same issue - I will link https://access.redhat.com/solutions/2769531
*** This bug has been marked as a duplicate of bug 1394740 ***