Bug 1294629 - Improve loading external VMs speed
Summary: Improve loading external VMs speed
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: General
Version: 3.6.3
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ovirt-4.1.0-alpha
: 4.1.0.2
Assignee: Sharon Gratch
QA Contact: Nisim Simsolo
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-12-29 11:12 UTC by Shahar Havivi
Modified: 2017-02-06 08:03 UTC (History)
7 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2017-02-01 14:42:33 UTC
oVirt Team: Virt
Embargoed:
rule-engine: ovirt-4.1+
nsimsolo: testing_plan_complete+
rule-engine: planning_ack+
rule-engine: devel_ack+
mavital: testing_ack+


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
oVirt gerrit 57418 0 master ABANDONED v2v: On demand loading of external VMs info 2016-06-10 08:22:15 UTC
oVirt gerrit 57973 0 master MERGED v2v: Load info only for subset of external VMs 2016-06-08 13:04:10 UTC
oVirt gerrit 58468 0 master MERGED v2v: Fetch only VM names from external host 2016-06-09 14:19:34 UTC
oVirt gerrit 60409 0 master MERGED webadmin: v2v-improve loading of external vms 2016-08-11 10:45:34 UTC

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


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