[ovirt-users] oVirt 4.2 - Removed disk remains in VM OS with hooks?

[Zip]

> 
>> I am having an issue where when I use the REST API to connect a snapshot from
>> another VM to a Backup-Appliance-VM, after the clone when I remove the Disk
>> and delete the Snapshot, the disk remains in the Backup-Appliance-VM as
>> /dev/sdb ot /dev/vdb.
>> 
>> If I reboot the Bakup-Applicance-VM the disk disappears.
>> 
>> If I manually remove the disk by "echo 1 > /sys/block/sdb/device/delete² the
>> disk will disappear, but if I rescan the scsi bus, it is found and shows up
>> again in the VM OS, but the oVirt WebGUI does NOT show it as connected.
> 
> -- The first part is expected - the 2nd isn't.
> 
> What are you referring to as the first and second part?

‹ I understand why the disk is seen after it was detached (stale device),
not why it comes back after rescan, which seems to suggest it is not
detached properly. 


If I pass an API call to reboot, the VM reboots and the stale disks are
still connected, however if I pass an API call to shutdown, the stale disks
are removed. Is there something else that can be passed to the reboot API
call to have it disconnect whatever the shutdown does? If not, is there a
way to defer an API call as my backup VM is what is calling the API, it cant
call to start itself if it is off due to a shutdown call?

I dont see any errors in the logs while tailing with:
tail /var/log/ovirt-*/* -f


> 
>  
>> 
>> I am also not able to attach any other disks as it complains of :
>> 
>> HotPlugDiskVDS failed: internal error: unable to execute QEMU command
>> '__com.redhat_drive_add': Duplicate ID 'drive-scsi0-0-0-2' for drive
>> 
>> I did see that others in the past have gotten around this issue by rebooting
>> the Backup-Appliance-VM and then continuing on with the next VM backup and
>> looping through backup-reboot-backup-reboot-etc.
>> 
>> Anyone have an idea on how to solve this issue and remove the hooks from the
>> guest OS?
>> 
>> Steps to reproduce this issue:
>> 
>> 1. Create a backup appliance VM to be used for the backup script execution
>> 2. Currently I have the Vms set to virtio with threaded I/O enabled. Also
>> tried virtio_scsi with same result.
>> 3. Using REST API ­ make snapshot of target VM
>> 4. Using REST API ­ fetch vm metadata
>> 5. Using REST API ­ attach the snapshot/disk to the Backup-Appliance-VM
>> 6. dd the drive to backup folder
>> 7. Using REST API ­ remove the disk from the Backup-Appliance-VM
>> 8. Using REST API ­ delete the snapshot
>> 9. ** Check the guest OS of the Backup-Appliance-VM and the mounted drive
>> from the backup above still appears and behaves as mentioned in comments
>> above.
>> 
> 
> ‹ There are many details missing, including versions of everything used, but
> logs would be most helpful here.
>  
> Versions for oVirt are all the most recent. This is a fresh install of the
> Hosted Engine. I will just script the backup to cycle through sdb, sdc, sdd,
> Š. Szzzz, just seems odd that once a disk is detached and a snapshot deleted,
> that the Backup_appliance-VM can still access the drive/snapshot?

‹ Unrelated note - do NOT use /dev/sdX to enumerate them. Especially on SCSI
bus, probing is done in parallel and they may have a different name next
time. Use /dev/disk/by-id paths.

Each time the backup is done, it only uses the device /dev/xxY to mount the
disk image. The actual backup is being catalogued using the uuid and vmname.

> 
> 
>> A second issue is that the above wont work when I have the Vms running on
>> MPIO iSCSI storage, so for testing I have moved to NFS4. Anyone have ideas
>> about either issue, I¹d love to hear ;)
> 
> ‹ Same - logs would be helpful here.
> 
> I will continue to dig through this issue and will post logs if stuck. I just
> wanted to know if there was anything obvious that I should be doing
> differently with iSCSI vs NFS with mounting disks/snapshots.

‹ Nope. 
‹ Y.

Zip
 

> 
> Zip
> 
> ‹ Y.
>  
>> 
>> Thanks
>> 
>> Irc.oftc.net <http://Irc.oftc.net>  #ovirt
>> zipur
>> 
>> 
>> 
>> _______________________________________________
>> Users mailing list
>> Users at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/users
>> 
> 



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/users/attachments/20180122/2d21abab/attachment.html>