Bug 1274708 - [z-stream clone 3.5.6] Second run of Windows VM fails because of access problem to sysprep payload
[z-stream clone 3.5.6] Second run of Windows VM fails because of access probl...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine (Show other bugs)
3.5.0
Unspecified Unspecified
high Severity urgent
: ovirt-3.5.6
: 3.5.6
Assigned To: Michal Skrivanek
Nisim Simsolo
virt
: ZStream
Depends On: 1190696
Blocks:
  Show dependency treegraph
 
Reported: 2015-10-23 08:13 EDT by rhev-integ
Modified: 2016-02-10 14:24 EST (History)
20 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 1190696
Environment:
Last Closed: 2015-12-01 14:06:36 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Virt
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 1755613 None None None Never
oVirt gerrit 38541 master MERGED core: load only managed device payload on run vm Never
oVirt gerrit 47562 ovirt-engine-3.5 MERGED core: load only managed device payload on run vm Never
Red Hat Product Errata RHBA-2015:2531 normal SHIPPED_LIVE Red Hat Enterprise Virtualization Manager 3.5.6 update 2015-12-01 19:05:21 EST

  None (edit)
Comment 1 Red Hat Bugzilla Rules Engine 2015-10-27 07:10:58 EDT
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 07:12:22 EST
Verified: 
rhevm-3.5.6.1-0.1.el6ev (vt18)
qemu-kvm-rhev-2.1.2-23.el7_1.10.x86_64
libvirt-client-1.2.8-16.el7_1.4.x86_64
vdsm-4.16.28-1.el7ev.x86_64
sanlock-3.2.2-2.el7.x86_64

Scenario:
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 12:21:58 EST
Thanks.  Do we have an ETA for 3.5.6?

- Greg Scott
Comment 9 Greg Scott 2015-11-06 16:34:00 EST
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 08:38:56 EST
(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 14:06:36 EST
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://rhn.redhat.com/errata/RHBA-2015-2531.html

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