Bug 1186230 - [RFE] Meaningful selection of the memory snapshot's location
Summary: [RFE] Meaningful selection of the memory snapshot's location
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: RFEs
Version: ---
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ovirt-3.6.0-rc
: 3.6.0
Assignee: Idan Shaby
QA Contact: Kevin Alon Goldblatt
URL:
Whiteboard: storage
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-01-27 10:32 UTC by Allon Mureinik
Modified: 2016-02-10 19:20 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-11-27 07:48:44 UTC
oVirt Team: Storage
Embargoed:
rule-engine: ovirt-3.6.0+
ylavi: planning_ack+
rule-engine: devel_ack+
rule-engine: testing_ack+


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
oVirt gerrit 40433 0 master MERGED core: move logic regarding memory storage handling 2020-04-01 06:08:29 UTC
oVirt gerrit 40434 0 master MERGED core: redesign MemoryStorageHandler to be a singleton 2020-04-01 06:08:28 UTC
oVirt gerrit 40435 0 master MERGED core: redesign MemoryStorageHandlerTest to use mocks 2020-04-01 06:08:28 UTC
oVirt gerrit 40436 0 master MERGED core: add more tests to MemoryStorageHandlerTest 2020-04-01 06:08:28 UTC
oVirt gerrit 40437 0 master MERGED core: redesign MemoryStorageHandler to use filters 2020-04-01 06:08:28 UTC
oVirt gerrit 40438 0 master MERGED core: add MemoryStorageHandler the ability to sort 2020-04-01 06:08:28 UTC
oVirt gerrit 42143 0 master MERGED core: log the selected storage domain for memory volumes 2020-04-01 06:08:28 UTC

Description Allon Mureinik 2015-01-27 10:32:47 UTC
Description of problem:
When creating a live snapshot with memory, the engine simply queries all the domains in the VM's DC and iterates them until it finds one which is active and has sufficient free space.

Since databases do not provide any guarantee on the order of rows selected from them (at least not without providing an ORDER BY clause, which we don't do), the domain that's eventually chosen is essentially chosen at random.

The engine should attempt to make some informed decision about the storage domain to use. At the very least, we should prioritize according to the location of the VM disks.

Conceptually:

    possibleStorageDomains = 
        SELECT sdId, COUNT(number of disks THIS vm has on it)
        FROM   storageDomains

    for (domain : possibleStorageDomains) {
        if (hasSpaceForMemoryVolume(domain)) {
            return domain;
        }
    }

Comment 1 Allon Mureinik 2015-01-27 10:39:26 UTC
Note: Solving bug 1150245 will reduce the severity of THIS ONE, but it's still important to start with a good default, and move the volume as a last resort, not as a common practice.

Comment 2 Max Kovgan 2015-06-28 14:11:56 UTC
ovirt-3.6.0-3 release

Comment 3 Kevin Alon Goldblatt 2015-11-12 10:40:20 UTC
Hi,

Can you please provide the steps to reproduce. From the tracker I understand that an info log has been added for the storage domain that was selected to store the vm's memory volumes.

Comment 4 Allon Mureinik 2015-11-12 11:54:42 UTC
Idan - can you please add an explanation here?

Comment 5 Idan Shaby 2015-11-12 14:05:14 UTC
Sure - this feature introduces the ability to wisely select a candidate (storage domain) to store the memory volumes when creating a live snapshot with memory.

First, we run a series of filters on the storage domains in the pool, one after another:
1. Status filter - filters non active domains from the list.
2. Type filter - filters non data domains from the list.
3. Space requirements filter - filters the domains that don't meet the space requirements from the list.

Second, we use a nested sort to sort the list of storage domains that were left according to the following rules:
1. The domain that contains the biggest number of vm disks will be first.
2. File domains will be first.
3. The domain that has the largest available disk space will be first.

* Nested sort means that if two or more domains meet one condition equally (for example domains with the same number of vm disks), those domains will be sorted among themselves according to the next condition.

And indeed, finally the details of the storage domain that was chosen (the first in the list) are logged.

Comment 6 Idan Shaby 2015-11-18 11:29:28 UTC
Adding general steps for testing this feature:

1. Create a series of storage domains. Each one with different characteristics as noted in comment 5.
2. Create a vm with one or more disks.
3. Run a scenario where a memory snapshot is created (hibernate, snapshot with memory, etc.).
4. Verify that the logged storage domain is the one you expected it to be according to the rules in comment 5.

Comment 7 Idan Shaby 2015-11-18 15:16:39 UTC
If it helps to find the log's record, this is its template:
"The memory volumes of VM (name '<vm_name>', id '<vm_id>') will be stored in storage domain (name '<domain_name>', id '<domain_id>')"

Comment 8 Kevin Alon Goldblatt 2015-11-19 08:53:56 UTC
Tested with the following code:
-----------------------------------
rhevm-3.6.0.3-0.1.el6.noarch
vdsm-4.17.10.1-0.el7ev.noarch

Verified with the following steps:
----------------------------------
1. Created 4 domains as follows:  a - with 6 vms, b - with no vms and lots of space, c - with 2 vms but less space and d - which is a non-data domain.
2. Created a vm with 3 disks and stared the vm (2 disks on domain 'c')
3. Created a snapshot with memory
4. The memory snapshot is created correctly on storage domain c as follows:
The domain is Active
The domain is a Data domain
The domain has enough available space
The domain contains most of the disks from the VM


Moving to VERIFIED!

Comment 9 Sandro Bonazzola 2015-11-27 07:48:44 UTC
Since oVirt 3.6.0 has been released, moving from verified to closed current release.


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