Bug 1280351
| Summary: | The flow of creating a Vm based on a template (resource allocation=thin) is wrong | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [oVirt] ovirt-engine | Reporter: | Ori Gofen <ogofen> | ||||
| Component: | BLL.Storage | Assignee: | Maor <mlipchuk> | ||||
| Status: | CLOSED NOTABUG | QA Contact: | Aharon Canan <acanan> | ||||
| Severity: | high | Docs Contact: | |||||
| Priority: | high | ||||||
| Version: | 3.6.0.2 | CC: | acanan, amureini, bugs, mlipchuk | ||||
| Target Milestone: | ovirt-3.6.1 | Flags: | amureini:
ovirt-3.6.z?
ogofen: planning_ack? ogofen: devel_ack? ogofen: testing_ack? |
||||
| Target Release: | 3.6.1 | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | storage | ||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2015-11-11 16:25:53 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: | |||||||
| Attachments: |
|
||||||
If this is real, it's awfully wrong. Amit, at this week's QA contact, please take a look. I already took a look at it and talked with Ori about this, taking this for now 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 Template volumes: ./e5d21cb6-4f0e-4899-868b-0c0c61216cf6: 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: ./99c0501d-1fde-41f0-910d-cce7e01f5931: 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 |
Created attachment 1092779 [details] logs 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): rhevm-3.6-0.3 How reproducible: 100% 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