Bug 1186230
| Summary: | [RFE] Meaningful selection of the memory snapshot's location | ||
|---|---|---|---|
| Product: | [oVirt] ovirt-engine | Reporter: | Allon Mureinik <amureini> |
| Component: | RFEs | Assignee: | Idan Shaby <ishaby> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Kevin Alon Goldblatt <kgoldbla> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | --- | CC: | ahadas, amureini, bugs, ecohen, gklein, iheim, ishaby, lsurette, michal.skrivanek, rbalakri, tnisan, yeylon |
| Target Milestone: | ovirt-3.6.0-rc | Keywords: | FutureFeature, Improvement |
| Target Release: | 3.6.0 | Flags: | rule-engine:
ovirt-3.6.0+
ylavi: planning_ack+ rule-engine: devel_ack+ rule-engine: testing_ack+ |
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | storage | ||
| Fixed In Version: | Doc Type: | Enhancement | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2015-11-27 07:48:44 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | Storage | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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. ovirt-3.6.0-3 release 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. Idan - can you please add an explanation here? 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. 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. 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>')" 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! Since oVirt 3.6.0 has been released, moving from verified to closed current release. |
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; } }