Bug 1274708

Summary: [z-stream clone 3.5.6] Second run of Windows VM fails because of access problem to sysprep payload
Product: Red Hat Enterprise Virtualization Manager Reporter: rhev-integ
Component: ovirt-engineAssignee: Michal Skrivanek <michal.skrivanek>
Status: CLOSED ERRATA QA Contact: Nisim Simsolo <nsimsolo>
Severity: urgent Docs Contact:
Priority: high    
Version: 3.5.0CC: dornelas, ecohen, gklein, gscott, istein, jbelka, lpeer, lsurette, mavital, michal.skrivanek, nashok, nsimsolo, omansecurity, pzhukov, rbalakri, Rhev-m-bugs, rhodain, sknauss, tjelinek, yeylon
Target Milestone: ovirt-3.5.6Keywords: ZStream
Target Release: 3.5.6   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: virt
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 1190696 Environment:
Last Closed: 2015-12-01 19:06:36 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:
Bug Depends On: 1190696    
Bug Blocks:    

Comment 1 Red Hat Bugzilla Rules Engine 2015-10-27 11:10:58 UTC
Fixed bug tickets must have target milestone set prior to fixing them. Please set the correct milestone and move the bugs back to the previous status after this is corrected.

Comment 5 Nisim Simsolo 2015-11-05 12:12:22 UTC
rhevm- (vt18)

1. Create new windows VM, seal VM and power it off.
2. Edit VM > initial run, verify cloud init/sysprep checkbox is unchecked.
3. Run VM.
4. Verify VM is running without sysprep.
5. power off VM, enable sysprep and run VM.
6. Verify VM is running with sysprep.
7. power off VM, start via 'Run' button, poweroff immediately (bug description scenario)
8. Run VM again. Verify VM is running properly without sysprep payload attached.

Comment 6 Greg Scott 2015-11-05 17:21:58 UTC
Thanks.  Do we have an ETA for 3.5.6?

- Greg Scott

Comment 9 Greg Scott 2015-11-06 21:34:00 UTC
The problem is only partially fixed.  Apparently, when the VM is first started with "run once", it still tries (incorrectly) to attach the floppy on the next power up after the sysprep mini-setup run finishes.  When the VM is first started with the normal "run", things now behave as expected on second powerup.

The problem also has unpleasant consequences.  When 3 VMs fail to start on a host, RHEV-M declares that host to be in an error state for the next 30 minutes. So in a scenario with lots of pooled VMs, all doing a second powerup and failing because of the floppy error, before too long, every host in the cluster will fail to start a VM 3 times, which pushes every RHEV-H host in the cluster into an error state for 30 minutes.  With all the hosts in this error state, no VMs can start or migrate and the cluster is pretty much out of commission.  

Here is some customer feedback on the hotfix for 3.5.5 based on this patch from support case number 01518293.

After hotfix was applied:
Systems no longer cause boot error for readwrite sysprep floppy on the first powerup after the initial sysprep and then VM shutdown. The sysprep floppy is not presented at all the to VM on the first powerup post sysprep then shutdown (this is the VMs 2nd powerup), which is the correct and expected behavior.
This ONLY affects systems if started with the "Run" option.

Systems started with "Run Once" option still have the problem where, on the next powerup of the VM post the sysprep then shutdown (the VMs 2nd powerup), the VMs are told to again attach to the sysprep floppy (error), and also in the process told to attach this floppy in readwrite state (file presented is with readonly permmissions).

Comment 11 Michal Skrivanek 2015-11-25 13:38:56 UTC
(In reply to Greg Scott from comment #9)

this is handled in bug 1240900 scheduled for 3.5.7

Comment 12 errata-xmlrpc 2015-12-01 19:06:36 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.