Bug 1136719 - Faulty storage allocation checks when importing a VM from ovf
Summary: Faulty storage allocation checks when importing a VM from ovf
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: oVirt
Classification: Retired
Component: ovirt-engine-core
Version: 3.4
Hardware: Unspecified
OS: All
medium
medium
Target Milestone: ---
: 3.5.0
Assignee: Vered Volansky
QA Contact: Kevin Alon Goldblatt
URL:
Whiteboard: storage
Depends On:
Blocks: 960934
TreeView+ depends on / blocked
 
Reported: 2014-09-03 07:12 UTC by Vered Volansky
Modified: 2016-02-10 17:48 UTC (History)
18 users (show)

Fixed In Version: ovirt-engine-3.5.0_beta2
Clone Of: 1053746
Environment:
Last Closed: 2014-10-17 12:31:23 UTC
oVirt Team: Storage
Embargoed:


Attachments (Terms of Use)

Description Vered Volansky 2014-09-03 07:12:49 UTC
The storage requirements for each disk in the imported VM:

      | File Domain                             | Block Domain
 -----|-----------------------------------------|-------------
 qcow | preallocated : 1.1 * disk capacity      |1.1 * min(used ,capacity) 
      | sparse: 1.1 * min(used ,capacity)       |
 -----|-----------------------------------------|-------------
 raw  | preallocated: disk capacity             |disk capacity
      | sparse: min(used,capacity)

Comment 1 Vered Volansky 2014-09-03 08:10:14 UTC
Disregard bug description (comment #0).
The scenario is conducted through ImportVmFromConfigurationCommand.
This is triggered by either by importing a vm from ovf, or importing a storage domain. In both cases the disks already exist in the system, so just make sure there storage allocation tests always pass on these scenarios.

Comment 2 Vered Volansky 2014-09-08 13:40:29 UTC
All the scenarios for this command should never get to the storage allocations, so the inheritance is good as it is. Moving straight to ON_QA.
Fixed In Version: ovirt-3.5.0-beta2

What should be verified is that this command never fails on storage space when importing a vm with disks.

Comment 3 Kevin Alon Goldblatt 2014-09-10 11:19:22 UTC
Hi,

Please provide detailed steps to reproduce / verify this bz.

Comment 4 Vered Volansky 2014-09-11 09:51:33 UTC
There are two scenarios for this command:

One scenario is importing a vm from as a new vm. In this scenario the disks are created on the Storage domain BEFORE ImportVmCommand.CDA(). So the storage allocation validation should be done when adding the disks. Only after that ImportVmCommand.CDA() is called. We want to make sure that at this point, storage allocation validations will always pass, even if there is no more space at the storage domain.
This could be checked as follows:
Prerequisite:
1. A vm with disks at your discretion.
2. A Storage with just enough space for above disks. Not enough for twice as much space consumed by this VM.

Now -
1. Import the Vm (using REST API).
2. Make sure the command does not fails on ImportVmCommand.CDA().
More specifically - the command should pass on AddDiskCommand.CDA() and then again on ImportVmCommand.CDA().

The second scenario is just registering an existing VM to the domain:
1. Create VM with 7 disks, each disk 1 GB
2. Export the VM
3. Detach the Storage Domain
4. Attach the Storage Domain to another DC
5. Activate it
6. Create disks on the Storage Domain until its free space is < 7 GB
7. Try to import the VM that you exported - Should fail on CDA
8. Try to register the VM - should succeed

Comment 5 Kevin Alon Goldblatt 2014-09-16 07:55:06 UTC
Moving to Verified. Tested this with the following scenario

Created a block storage domain with 40GB space
Created a vm and 1 disk of 32 GB. The ovf file is uploaded
Detach the Storage Domain (make sure this is not the master)
Attach the Storage Domain again. (The allocation validation is NOT done here - this is as expected)
Import the VM again - the registration is performed here. (The allocation validation is NOT done here - this is as expected)

Comment 6 Sandro Bonazzola 2014-10-17 12:31:23 UTC
oVirt 3.5 has been released and should include the fix for this issue.


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