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-engine | Assignee: | Michal Skrivanek <michal.skrivanek> |
Status: | CLOSED ERRATA | QA Contact: | Nisim Simsolo <nsimsolo> |
Severity: | urgent | Docs Contact: | |
Priority: | high | ||
Version: | 3.5.0 | CC: | 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.6 | Keywords: | 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: | |
Embargoed: | |||
Bug Depends On: | 1190696 | ||
Bug Blocks: |
Comment 1
Red Hat Bugzilla Rules Engine
2015-10-27 11:10:58 UTC
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. Thanks. Do we have an ETA for 3.5.6? - Greg Scott 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). (In reply to Greg Scott from comment #9) this is handled in bug 1240900 scheduled for 3.5.7 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 |