Bug 1382543

Summary:	'hosted-engine --upgrade-appliance' backup of existing rhevm takes ages
Product:	Red Hat Enterprise Virtualization Manager	Reporter:	Marcus West <mwest>
Component:	ovirt-hosted-engine-setup	Assignee:	Sandro Bonazzola <sbonazzo>
Status:	CLOSED DUPLICATE	QA Contact:	meital avital <mavital>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	4.0.3	CC:	emahoney, gklein, lsurette, mkalinin, mwest, sbonazzo, stirabos, ykaul
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:	integration
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-10-10 09:54:18 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Integration	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

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.