Bug 1294629 - Improve loading external VMs speed
Improve loading external VMs speed
Product: ovirt-engine
Classification: oVirt
Component: General (Show other bugs)
Unspecified Unspecified
high Severity high (vote)
: ovirt-4.1.0-alpha
Assigned To: Sharon Gratch
Nisim Simsolo
: Improvement
Depends On:
  Show dependency treegraph
Reported: 2015-12-29 06:12 EST by Shahar Havivi
Modified: 2017-02-06 03:03 EST (History)
7 users (show)

See Also:
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:
Last Closed: 2017-02-01 09:42:33 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: Virt
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
rule-engine: ovirt‑4.1+
nsimsolo: testing_plan_complete+
rule-engine: planning_ack+
rule-engine: devel_ack+
mavital: testing_ack+

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 57418 master ABANDONED v2v: On demand loading of external VMs info 2016-06-10 04:22 EDT
oVirt gerrit 57973 master MERGED v2v: Load info only for subset of external VMs 2016-06-08 09:04 EDT
oVirt gerrit 58468 master MERGED v2v: Fetch only VM names from external host 2016-06-09 10:19 EDT
oVirt gerrit 60409 master MERGED webadmin: v2v-improve loading of external vms 2016-08-11 06:45 EDT

  None (edit)
Description Shahar Havivi 2015-12-29 06:12:12 EST
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 06:34:33 EST
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 17:28:46 EDT
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 06:39:54 EDT
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 04:37:32 EDT
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 10:59:18 EDT
since the required VDSM API change will land in 4.1, postponing to 4.1
Comment 6 Sandro Bonazzola 2016-12-12 09:01:45 EST
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 04:14:07 EST
Verification build: 

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.

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.