Bug 1382543 - 'hosted-engine --upgrade-appliance' backup of existing rhevm takes ages
Summary: 'hosted-engine --upgrade-appliance' backup of existing rhevm takes ages
Keywords:
Status: CLOSED DUPLICATE of bug 1343593
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-hosted-engine-setup
Version: 4.0.3
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: ---
: ---
Assignee: Sandro Bonazzola
QA Contact: meital avital
URL:
Whiteboard: integration
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-10-07 03:12 UTC by Marcus West
Modified: 2016-11-22 08:40 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-10-10 09:54:18 UTC
oVirt Team: Integration
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Marcus West 2016-10-07 03:12:24 UTC
## Description of problem:

When upgrading 3.6 to 4.0 (hosted engine, rhv-h, iscsi storage), it takes ages to 'back up' the existing rhevm instance.  Is there any technical reason why we can't just install the new rhevm on a new logical volume? (or file)

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

ovirt-hosted-engine-setup-2.0.2.2-2.el7ev.noarch

## How reproducible:

Always.  I only tried this with iscsi, have not tried nfs,FC.

## Steps to Reproduce:
1. install 3.6 initially (hosted engine, rhv-h, iscsi storage)
2. upgrade to 4.0

## Actual results:

It took 50 minutes to create the backup (qemu-img convert).  My upgrade eventually failed, then the subsequent rollback also took a similar time

## Expected results:

Would it be possible to just create a new lv? (or file, for nfs storage).  Then if rollback is required, just point things back to the original image.

## Additional info:

Comment 4 Simone Tiraboschi 2016-10-10 09:54:18 UTC
Our initial approach simply keep the original disk as it is renaming it as backup and deployed over a new one (new LV): as you pointed out backup creation and rollback were almost instantaneously.
The issue was that, due to other reasons, wasn't possible to switch the disk of the engine VM at engine eyes.
So out only option was to create the backup over a new disk and upgrade in place and this requires more time as you pointed out.

By the way, the size of the backup disk is 50 GB, if it took 50 minutes, it's working at an average speed of 17 MB/sec on sequential writes which today seams pretty on the low side: I'd suggest to also check the storage connection.

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

Comment 5 Marina Kalinin 2016-11-07 04:19:36 UTC
Marcus, Evan,

How long is that?
Should we create a kcs for this or documentation note?

Comment 6 Marcus West 2016-11-22 01:02:09 UTC
If it could have a negative impact on reliability, then lets leave it as it is then.  My test environment is made up of spare parts and is quite slow, so hopefully not a common deployment.

Comment 7 Simone Tiraboschi 2016-11-22 08:40:31 UTC
It copies the whole engine VM disk so, if your storage doesn't support sparse files, it's going to copy 50 GB.
Up to 10-15 minutes could be still reasonable.


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