Bug 1294629

Summary:	Improve loading external VMs speed
Product:	[oVirt] ovirt-engine	Reporter:	Shahar Havivi <shavivi>
Component:	General	Assignee:	Sharon Gratch <sgratch>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Nisim Simsolo <nsimsolo>
Severity:	high	Docs Contact:
Priority:	high
Version:	3.6.3	CC:	bugs, mavital, melewis, mgoldboi, michal.skrivanek, nsimsolo, tjelinek
Target Milestone:	ovirt-4.1.0-alpha	Keywords:	Improvement
Target Release:	4.1.0.2	Flags:	rule-engine: ovirt-4.1+ nsimsolo: testing_plan_complete+ rule-engine: planning_ack+ rule-engine: devel_ack+ mavital: testing_ack+
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:	With this update, the loading performance of external virtual machines from an external server has been improved for the VMware, KVM, and Xen. Previously, when displaying a list of virtual machines libvirt was asked for the full information for each virtual machine when only the virtual machine names were required. Now, libvirt is only asked for the virtual machines names at the first import dialog and only imports the full virtual machine data list after the user has selected the required virtual machines.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-02-01 14:42:33 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Virt	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Shahar Havivi 2015-12-29 11:12:12 UTC

When probing VMs to import from external provider (currently vCenter) each VM take ~5 seconds because we ask libvirt to provide storage information on each VM.

We can improve that by not asking for the storage and adding a new verb to vdsm that returns the storage to specific VMs that the user will select to import

Comment 1 Shahar Havivi 2015-12-31 11:34:33 UTC

After checking more environments its looks like its ~0.5 second per VM.
Still suggested fix will speed the loading of VM list.

Comment 2 Moran Goldboim 2016-03-20 21:28:46 UTC

Due to capacity constrains, postponing for next release.
nevertheless this is a valid use case that should be supported.

Comment 3 Shahar Havivi 2016-03-22 10:39:54 UTC

The are two bottle neck in probing the VMs:
1. getting the xml description (75% of the load)
2. getting the disk size (25% of the load)

If we change the load will be reduce from the first dialog ie getting only the name and the status of the VMs but we still need the data when the user pass the VMs to the next dialog.

common scenarios:
1. User will select all the VMs we will not save time.
2. User will select some of the VMs we can save some time
3. User will select some of the VMs and the go back to change the the selection - load time can be even worse.

I don't think we need to change it for now until we know what are the common user behavior.

Comment 4 Michal Skrivanek 2016-04-08 08:37:32 UTC

I think it's worth it, listing only the names is a significant speedup mainly because you don't have to iterate over each VM(eliminating 100% of comment #3:)
Yes, in case of 1. it won't save anything, but in all other cases it would help a lot.

Comment 5 Tomas Jelinek 2016-06-20 14:59:18 UTC

since the required VDSM API change will land in 4.1, postponing to 4.1

Comment 6 Sandro Bonazzola 2016-12-12 14:01:45 UTC

The fix for this issue should be included in oVirt 4.1.0 beta 1 released on December 1st. If not included please move back to modified.

Comment 7 Nisim Simsolo 2017-01-02 09:14:07 UTC

Verification build: 
rhevm-4.1.0-0.3.beta2.el7
qemu-kvm-rhev-2.6.0-28.el7_3.2.x86_64
libvirt-client-2.0.0-10.el7_3.2.x86_64
vdsm-4.19.1-1.el7ev.x86_64
sanlock-3.4.0-1.el7.x86_64

Verification scenario:
1. Use RHEVM 4.1 with cluster and DC 4.1 compatibility: Load VMs from Xen, VMware and KVM.
2. Compare loading time to loading time of 4.0 Cluster and DC compatibility.

Results: 
VMware loading time with 4.1: 1.5
VMware loading time with 4.0: 13.8