Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1441935

Summary: [RFE] Users should be able to seal VMs from RHEV-M
Product: Red Hat Enterprise Virtualization Manager Reporter: rhev-integ
Component: RFEsAssignee: Shmuel Melamud <smelamud>
Status: CLOSED ERRATA QA Contact: Nisim Simsolo <nsimsolo>
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: jcoscia, kmorey, lsurette, mavital, melewis, mgoldboi, michal.skrivanek, mtessun, nsimsolo, rbalakri, rhev-integ, smelamud, srevivo, tjelinek, ykaul, zbrown
Target Milestone: ovirt-4.1.2Keywords: FutureFeature, ZStream
Target Release: ---Flags: lsvaty: testing_plan_complete-
Hardware: Unspecified   
OS: Unspecified   
URL: https://trello.com/c/dN08y1W2
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
The feature is documented here: http://www.ovirt.org/develop/release-management/features/virt-sysprep/
Story Points: ---
Clone Of: RHV_virt_sysprep Environment:
Last Closed: 2017-05-24 11:22:58 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Virt RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1335642    
Bug Blocks: 1462593    

Description rhev-integ 2017-04-13 06:43:48 UTC
+++ This bug is a downstream clone. The original bug is: +++
+++   bug 1335642 +++
======================================================================

Description of problem:
Currently, in order to properly "seal" (make a VM generic in preparation for cloning or template), it is a manual process or a painful RHEV-CLI process in order to use virt-sysprep. In RHEL+KVM (or CENTOS, Ubuntu, etc), this is not an issue. Our own Red Hat documentation suggests a painful manual removal of SSH keys, UDEV rules, MAC addresses, system id, and hostname. It is the complete opposite of automation.

In order to run sys-virtprep in RHEV, you have to go through the trouble of deploying the RHEV-CLI, locate the the disk image, activate the logical volume, run virt-sysprep, deactivate the logical volume, then create the template back in RHEV-M. 

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

How reproducible:
Create a VM in RHEV. You are unable to utilize `virt-sysprep` or other libguestfs tools in a convenient manner.

Expected results:
Have an option in the template tab or VM tab to open a dialog box for sealing options.

(Originally by Jon Benedict)

Comment 1 rhev-integ 2017-04-13 06:43:56 UTC
I ran into this same issue at a customer site this week.

The process of building a template does seem archaic in comparison to the larger story we're delivering around hybrid cloud automation.

It would be helpful to have this functionality delivered from the UI for RHEL guests.

(Originally by Zak Berrie)

Comment 3 rhev-integ 2017-04-13 06:44:01 UTC
upstream tracking https://trello.com/c/dN08y1W2

(Originally by michal.skrivanek)

Comment 4 rhev-integ 2017-04-13 06:44:07 UTC
may appear in 4.1.z or even 4.1 GA

(Originally by michal.skrivanek)

Comment 7 Nisim Simsolo 2017-04-30 11:23:09 UTC
Reassigned, Template is not sealed: users, SSH keys, UDEV rules, MAC addresses, system ID and hostname are not removed from the template.

Verification build: 
ovirt-engine-4.1.2-0.1.el7
vdsm-4.19.11-1.el7ev.x86_64
libvirt-client-2.0.0-10.el7_3.5.x86_64
qemu-kvm-rhev-2.6.0-28.el7_3.9.x86_64
sanlock-3.4.0-1.el7.x86_64

Testing scenario:
1. Create RHEL7 VM, run VM and verify VM is running properly.
2. Power off VM -> make template and check "seal template" checkbox.
3. Create VM from sealed template.
4. Run VM and verify VM is sealed.

Actual results:
VM is not sealed: users, SSH keys, UDEV rules, system ID and hostname still exist.

Comment 8 Shmuel Melamud 2017-04-30 12:43:15 UTC
(In reply to Nisim Simsolo from comment #7)
Questions about verification:

1. SSH keys, system ID and hostname in the new VM were the same as in the old VM or different?
2. Did you verify that virt-sysprep utility is installed on all hosts in the cluster and works properly with libvirt backend if run under vdsm user?

Comment 15 Michal Skrivanek 2017-05-03 12:36:36 UTC
*** Bug 1436219 has been marked as a duplicate of this bug. ***

Comment 18 Nisim Simsolo 2017-05-08 09:11:37 UTC
Verification build:
ovirt-engine-4.1.2-0.1.el7
vdsm-4.19.11-1.el7ev.x86_64
libvirt-client-2.0.0-10.el7_3.5.x86_64
sanlock-3.4.0-1.el7.x86_64
qemu-kvm-rhev-2.6.0-28.el7_3.9.x86_64
virt-sysprep 1.32.7rhel=7,release=3.el7_3.2,libvirt

Verification scenario: 
Test plan added to external trackers

Comment 22 errata-xmlrpc 2017-05-24 11:22:58 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

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

https://access.redhat.com/errata/RHEA-2017:1280