Bug 1739377

Summary: clone VM from snapshot sets to use cloud-init
Product: [oVirt] ovirt-engine Reporter: Lucie Leistnerova <lleistne>
Component: Frontend.WebAdminAssignee: Steven Rosenberg <srosenbe>
Status: CLOSED CURRENTRELEASE QA Contact: Beni Pelled <bpelled>
Severity: low Docs Contact:
Priority: unspecified    
Version: 4.3.6CC: ahadas, bugs, mavital, michal.skrivanek, mtessun, rdlugyhe, srosenbe
Target Milestone: ovirt-4.4.1Flags: pm-rhel: ovirt-4.4+
sbonazzo: planning_ack?
sbonazzo: devel_ack?
sbonazzo: testing_ack?
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: rhv-4.4.0-32 Doc Type: Bug Fix
Doc Text:
Previously, creating a snapshot did not correctly save the Cloud-Init/Sysprep settings for the guest OS. If you tried to clone a virtual machine from the snapshot, it did not have valid values to initialize the guest OS. The current release fixes this issue. Now, creating a snapshot correctly saves the the Cloud-Init/Sysprep configuration for the guest OS.
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-07-08 08:27:07 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Virt RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Initial run tabs none

Description Lucie Leistnerova 2019-08-09 07:59:51 UTC
Created attachment 1602053 [details]
Initial run tabs

Description of problem:
When I have a VM with snapshot and cloud-init is not set, cloning VM from snapshot sets to use cloud-init.

Version-Release number of selected component (if applicable):
ovirt-engine-4.3.6-0.1.el7.noarch

How reproducible:
always


Steps to Reproduce:
1. create new VM, cloud-init in Initial run is not checked
2. create snapshot on that VM
3. clone VM from the snapshot

Actual results: clound-init is checked, see attachment


Expected results: clound-init is not checked

Comment 1 Steven Rosenberg 2019-11-04 11:07:49 UTC
One can easily fix this issue by initializing the VmInit control properly within the VmSnapshotListModel.java's cloneVM function. The larger issue is that when the original VM is actually set, we are not setting the other Vm Init controls as per the original VM and we should do that as well. There are I assume other fields that we are not inheriting properly from the original VM when cloning a snap shot which would require further testing and investigation.

The Snap Shot's information is Stored within the snapshots DB Table. A design question would be if we should add the VM Init fields (as wel as any other missing data) to this DB which may cause some performance issues elsewhere, or attempt to fetch the original VM within the cloneVM function and access the original values directly (although the problem here is if the original was changed, one should clone from the snapshot which is by definition what a snap shot is).

Of cause saving more data to the snapshots DB Table seems to be the most sense, but please advise accordingly.

Comment 2 Martin Tessun 2019-11-13 11:27:41 UTC
(In reply to Steven Rosenberg from comment #1)
> One can easily fix this issue by initializing the VmInit control properly
> within the VmSnapshotListModel.java's cloneVM function. The larger issue is
> that when the original VM is actually set, we are not setting the other Vm
> Init controls as per the original VM and we should do that as well. There
> are I assume other fields that we are not inheriting properly from the
> original VM when cloning a snap shot which would require further testing and
> investigation.
> 
> The Snap Shot's information is Stored within the snapshots DB Table. A
> design question would be if we should add the VM Init fields (as wel as any
> other missing data) to this DB which may cause some performance issues
> elsewhere, or attempt to fetch the original VM within the cloneVM function
> and access the original values directly (although the problem here is if the
> original was changed, one should clone from the snapshot which is by
> definition what a snap shot is).
> 
> Of cause saving more data to the snapshots DB Table seems to be the most
> sense, but please advise accordingly.

I believe you are right here. Please check with developers in that area and test with QE if and what perfomance impacts this might have. I don't expect any serious, but we should be sure.

Thanks!
Martin

Comment 3 Beni Pelled 2020-04-23 09:02:53 UTC
Verified with:
- RHV 4.4.0-0.32.master.el8ev

Verification steps:
2. Create a VM and make sure the cloud-init is unchecked 
3. Create a snapshot
4. Clone a new VM from the snapshot and make sure the cloud-init is unchecked on the new cloned VM

Result:
- The cloud-init is not checked on the new VM cloned from the snapshot.

Comment 4 Sandro Bonazzola 2020-07-08 08:27:07 UTC
This bugzilla is included in oVirt 4.4.1 release, published on July 8th 2020.

Since the problem described in this bug report should be resolved in oVirt 4.4.1 release, it has been closed with a resolution of CURRENT RELEASE.

If the solution does not work for you, please open a new bug report.