Bug 1869317

Summary: SCSI Hostdev Passthrough: VM snapshot is dropping attached scsi_hostdev.
Product: [oVirt] ovirt-engine Reporter: Nisim Simsolo <nsimsolo>
Component: BLL.VirtAssignee: Liran Rotenberg <lrotenbe>
Status: CLOSED CURRENTRELEASE QA Contact: Nisim Simsolo <nsimsolo>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 4.4.1.10CC: ahadas, bugs, dfodor, lrotenbe, nsimsolo
Target Milestone: ovirt-4.4.3Flags: pm-rhel: ovirt-4.4+
Target Release: 4.4.3.3   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: ovirt-engine-4.4.3.3 Doc Type: Bug Fix
Doc Text:
Previously, when host device was attached to the VM, the device wasn't written to the VM OVF. Therefore, when previewing or commiting from snapshot the device dropped. Now the host device will be written to the VM OVF and remain on snapshot operations. Only in case the VM isn't pinned to the original host it will be dropped.
 Story Points: ---
Clone Of: Environment:
Last Closed: 2020-11-11 06:42:24 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
vdsm.log
none
engine.log none

Description Nisim Simsolo 2020-08-17 13:38:48 UTC 
Description of problem:
After preview/commit snapshot of VM with SCSI passhtourh, the SCSI passthrough disk device is detached and VM failed to load entering into emergency mode (cannot find disk from /etc/fstab).

In WebAdmin, VM -> host devices tab, the device is not there anymore. custom property scsi_hostdev is kept.

Observing engine db shows that scsi_hostdev is not plugged:
engine=# select type,device,address,is_managed,is_plugged,is_readonly from vm_device where vm_id = '9087f513-d337-4331-b6d8-5fd52ee2fad9' and type='hostdev';
(0 rows)

Workaround for this issue is to add SCSI device again to the VM and run it with the snapshot.

Version-Release number of selected component (if applicable):
ovirt-engine-4.4.2.2-0.3.el8ev
vdsm-4.40.25-1.el8ev.x86_64
libvirt-daemon-6.0.0-25.module+el8.2.1+7154+47ffd890.x86_64
qemu-kvm-4.2.0-29.module+el8.2.1+7297+a825794d.x86_64

How reproducible:
always

Steps to Reproduce:
1. Run VM with SCSI passthrough and any of the scsi_hostdev custom property.
2. Connect VM, make partition of passthrough disk, format it and mount it.
3. Create snapshot (without memory)
4. Preview/commit snapshot

Actual results:
SCSI device is dropped from VM and Vm failed to boot.

Expected results:
SCSI device should not be dropped from snapshot.

Additional info:
engine.log and vdsm.log attached.
VM name: 1_rhel8_scsi_hd
Comment 1 Nisim Simsolo 2020-08-17 13:41:09 UTC 
Created attachment 1711616 [details]
vdsm.log
Comment 2 Nisim Simsolo 2020-08-17 13:41:27 UTC 
Created attachment 1711617 [details]
engine.log
Comment 3 Arik 2020-08-18 07:03:47 UTC 
Apparently VM host devices were never written to the OVF and that's why they are missing when previewing a snapshot
Comment 4 Nisim Simsolo 2020-10-14 12:10:10 UTC 
Verified:
ovirt-engine-4.4.3.5-0.5.el8ev
vdsm-4.40.32-1.el8ev.x86_64
libvirt-daemon-6.6.0-6.module+el8.3.0+8125+aefcf088.x86_64
qemu-kvm-5.1.0-10.module+el8.3.0+8254+568ca30d.x86_64

Verification scenario:
1. Run VM with SCSI passthrough and any of the scsi_hostdev custom property.
2. Connect VM, make partition of passthrough disk, format it and mount it. create new folder inside mount point and write some data inside it.
3. While VM is running Create snapshot (without memory)
4. Preview/commit snapshot.
   Verify hostdev was not dropped. run VM  and verify data exists in mount point.
5. Repeat steps 1-4 this time create snapshot when VM is powered off.
6. Repeat steps 1-5, this time, before previewing/committing the snapshot, remove hostdev from VM (from WebAdmin -> click on VM name -> host devices tab: remove device)
   After previewing/committing snapshot, verify hostdev added to VM. run VM  and verify data exists in mount point.
Comment 5 Sandro Bonazzola 2020-11-11 06:42:24 UTC 
This bugzilla is included in oVirt 4.4.3 release, published on November 10th 2020.

Since the problem described in this bug report should be resolved in oVirt 4.4.3 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.