Bug 1280351 - The flow of creating a Vm based on a template (resource allocation=thin) is wrong
The flow of creating a Vm based on a template (resource allocation=thin) is w...
Product: ovirt-engine
Classification: oVirt
Component: BLL.Storage (Show other bugs)
Unspecified Unspecified
high Severity high (vote)
: ovirt-3.6.1
: 3.6.1
Assigned To: Maor
Aharon Canan
Depends On:
  Show dependency treegraph
Reported: 2015-11-11 09:32 EST by Ori Gofen
Modified: 2016-05-25 21:50 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2015-11-11 11:25:53 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: Storage
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
amureini: ovirt‑3.6.z?
ogofen: planning_ack?
ogofen: devel_ack?
ogofen: testing_ack?

Attachments (Terms of Use)
logs (1.79 MB, application/x-gzip)
2015-11-11 09:32 EST, Ori Gofen
no flags Details

  None (edit)
Description Ori Gofen 2015-11-11 09:32:16 EST
Created attachment 1092779 [details]

Description of problem:
The operation of creating a Vm from a template with allocation policy: thin can  be described roughly in three steps:

1. Creating a vm according to template's ovf parameters.
2. Creating a snapshot volume leaf which refers to template's base disk.
3. Attaching the images to the Vm.

This basic flow creates a Vm that basically reads from templates disk and write 'deltas' to it's snapshot.
from oVirt's docs:
"Virtual machines created based on a template depend on that template. This means that you cannot remove that template from the Manager".

What is actually happening is that when creating such a Vm, a copy of template's disk is created on host and then a snapshot volume is also created on based on this volume, it is like a mixture of both cloning a Vm from template  
and creating a thin Vm based on template, a mixture that we don't want because it has no use.

btw this vol-chain consist of 2 volumes that do not share the same image uuid, which is an absurd state.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Have a Vm with nfs disk
2. Create a template 
3. Create a Vm based on this template, check resource allocation=thin

Actual results:
A cloned Vm based on Template + snapshot is created.

Expected results:
The Vm should be created, 'thin', which means that a snapshot is created based on template's disk and refers to it's base vol.

Additional info:
* The behavior on Block is not the same as file, will be opened and described as  separate bug.

* this could be a vdsm bug, due to lack of time couldn't explore this issue further
Comment 1 Allon Mureinik 2015-11-11 10:44:37 EST
If this is real, it's awfully wrong.
Amit, at this week's QA contact, please take a look.
Comment 2 Maor 2015-11-11 11:02:34 EST
I already took a look at it and talked with Ori about this, taking this for now
Comment 3 Maor 2015-11-11 11:05:54 EST
I've taken a look into it.
VDSM seems to make hard links of the template volumes in the VM's images.
executing "ls -i" can show that the inode of the volumes are the same in the template and the VM.
Since there is no copy operation for thin this looks like not a bug
Comment 4 Maor 2015-11-11 11:09:28 EST
Template volumes: 

total 9
27483 -rw-rw----+ 9dc1e21b-8154-4ee3-9314-cf86ee1dda3b
27492 -rw-rw----+ 9dc1e21b-8154-4ee3-9314-cf86ee1dda3b.lease
27500 -rw-r--r--+ 9dc1e21b-8154-4ee3-9314-cf86ee1dda3b.meta

Vm based on Tempalte volumes:

total 28
27977 -rw-rw----+ 4aa52877-97b2-4ebe-811c-86b3610003bb
27996 -rw-rw----+ 4aa52877-97b2-4ebe-811c-86b3610003bb.lease
27995 -rw-r--r--+ 4aa52877-97b2-4ebe-811c-86b3610003bb.meta
27483 -rw-rw----+ 9dc1e21b-8154-4ee3-9314-cf86ee1dda3b
27492 -rw-rw----+ 9dc1e21b-8154-4ee3-9314-cf86ee1dda3b.lease
27500 -rw-r--r--+ 9dc1e21b-8154-4ee3-9314-cf86ee1dda3b.meta

The inode of 9dc1e21b-8154-4ee3-9314-cf86ee1dda3b is the same for the VM and the Template

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