Bug 1353137 - Memory volume placement should prefer shared to local domains
Summary: Memory volume placement should prefer shared to local domains
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: BLL.Storage
Version: 4.0.0
Hardware: All
OS: All
medium
medium
Target Milestone: ovirt-4.1.0-alpha
: 4.1.0.2
Assignee: Maor
QA Contact: Lilach Zitnitski
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-07-06 08:17 UTC by Allon Mureinik
Modified: 2017-02-01 14:45 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-02-01 14:45:36 UTC
oVirt Team: Storage
Embargoed:
rule-engine: ovirt-4.1+
rule-engine: planning_ack+
amureini: devel_ack+
ratamir: testing_ack+


Attachments (Terms of Use)
Screenshot of the dialog with the memory snapshot checkbox highlighted (341.38 KB, image/png)
2016-12-22 13:54 UTC, Allon Mureinik
no flags Details


Links
System ID Private Priority Status Summary Last Updated
oVirt gerrit 60298 0 master MERGED core: Rename storageTypeComparator to be more specific. 2016-07-11 15:05:03 UTC
oVirt gerrit 60299 0 master MERGED core: Add isShared method for readability 2016-07-11 15:05:14 UTC
oVirt gerrit 60300 0 master MERGED core: Introduce StorageTypeSharedComparator. 2016-07-11 15:05:21 UTC

Description Allon Mureinik 2016-07-06 08:17:42 UTC
Description of problem:
When selecting a domain to place memory volumes, there are currently three comparators that choose the target domain (see org.ovirt.engine.core.bll.memory.MemoryStorageHandler#getStorageDomainComparators):
1. The number of the VM's disks in the domain - prefer the domain where the VM has the most disks
2. Storage type - prefer file storage over block storage
3. Free space - prefer domains with more free space 

To improve resiliency, we should prefer shared domains over local domain as the second criteria (i.e., between the current [1] and [2]).

Comment 1 Sandro Bonazzola 2016-12-12 14:03:58 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 2 Lilach Zitnitski 2016-12-18 13:17:34 UTC
I'm not quite sure I understand how to check this bug. 
I've created a vm with 2 disks, one on shared domain and one on local, and took live snapshot with memory of both disks, and each new volume was created on the storage domain where the base disk is located (one on local and one on shared). 
Is there another way to check memory volumes created on shared storage domains before local storage domains? 
Thanks.

Comment 3 Allon Mureinik 2016-12-22 13:52:53 UTC
I think we have a misunderstanding here. I'll attempt to explain, and apologize in advance if I'm rehashing obvious facts.

When you take a snapshot of a VM, each image (=disk) will get another volume in its chain, on the same domain, as you noted.

When you take a LIVE snapshot, you have the option to also save the VM's memory state (this is ENABLED by default, but can be disabled manually. See the attached screenshot for details on how to do this via the webadmin).
This state is saved in two more volumes - one containing the memory dump and a smaller one containing libvirt's XML that's currently running.
The engine automatically calculates where to place these volumes according to the following logic:

1. Start with all the DATA domains in the DC which are UP and have sufficient storage space.
2. Then, sort the domains according to the following properties, and choose the best target:
A. Prefer the domain that has the most of the VM's disks. If several domains have the same number of the VM's disks, then:
B. Prefer shared domains to local domains. If there's still no clear "winner":
C. Prefer file-based domains to block-based domain. If there's still no clear "winner":
D. Prefer the domain with the most free space. If there's still no clear "winner", just choose one of the "best suited" domains.

In the log, you  should something like this:
2016-12-22 15:36:09,861 INFO  [org.ovirt.engine.core.bll.memory.MemoryStorageHandler] (default task-89) [58f49fb5] The memory volumes of VM (name 
'allon_rhel66_host_1', id '9744e7ef-a064-4dd6-b9a7-c7419467c7ab') will be stored in storage domain (name 'RHEV-TLV-NESTED-NFS', id '658c207b-64a4-
489a-916a-d295700dffa0')

The scenario you described sounds great (one VM with two disks, one on a local domain and one of a shared domain). Make sure both domains have sufficient free space for the snapshot and memory volume (should the engine decide to place it there). Then, just take a live snapshot of the VM, and check the log for the location of the memory volumes. If they are on the shared domain, this bug is VERIFIED. If they are on the local domain, we've failed :-(

Thanks!

Comment 4 Allon Mureinik 2016-12-22 13:54:05 UTC
Created attachment 1234801 [details]
Screenshot of the dialog with the memory snapshot checkbox highlighted

Comment 5 Lilach Zitnitski 2016-12-22 15:09:22 UTC
Thanks Allon, the way to confirm the memory volume location it's exactly what I was missing.

--------------------------------------
Tested with the following code:
----------------------------------------
ovirt-engine-4.1.0-0.2.master.20161214234138.gitc23fdcc.el7.centos.noarch
vdsm-4.18.999-1184.git090267e.el7.centos.x86_64

Tested with the following scenario:

Steps to Reproduce:
1. create new vm in a local DC with 2 disks, one on shared storage domain and one on local storage domain
2. start the vm
3. take live snapshot with memory

Actual results:
memory volumes created on the shared storage domain 
2016-12-22 16:58:47,321+02 INFO  [org.ovirt.engine.core.bll.memory.MemoryStorageHandler] (default task-13) [05f6b237-6c8c-4fc3-9929-b47daa72cdc8] The memory volumes of VM (name 'lil
ach-test-vm', id 'c31d8ce1-9a0e-4d62-bc05-25b1c1663856') will be stored in storage domain (name 'lilach-shared', id '8a967257-8b66-494a-b229-cc734a4e6407')

Moving to VERIFIED!


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