Bug 1446058

Summary: [RFE] vdsm-tool helper to reattach formerly-detached devices
Product: [oVirt] ovirt-engine Reporter: Michael Burman <mburman>
Component: BLL.VirtAssignee: bugs <bugs>
Status: CLOSED WONTFIX QA Contact: Michael Burman <mburman>
Severity: high Docs Contact:
Priority: unspecified    
Version: 4.1.1.8CC: bugs, danken, mburman, michal.skrivanek, myakove, tjelinek
Target Milestone: ---Keywords: Automation, FutureFeature
Target Release: ---Flags: rule-engine: planning_ack?
rule-engine: devel_ack?
rule-engine: testing_ack?
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-11-14 11:25:32 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
Logs none

Description Michael Burman 2017-04-27 07:51:58 UTC
Created attachment 1274519 [details]
Logs

Description of problem:
VF leakage on start VM with VFIO host device.

When starting a VM with host device which is a VF and then shutting it down, the VF is leaked and didn't released on refresh caps. He considered taken by the engine and can't be used by other VMs.

Version-Release number of selected component (if applicable):
4.1.2-0.1.el7
vdsm-4.19.11-1.el7ev.x86_64

How reproducible:
100%

Steps to Reproduce:
1. Enable 1 VF on a capable sr-iov host
2. Add the VF to the VM as a host device
3. Run VM (VF is taken from host on refresh caps)
4. Shutdown the VM 

Actual results:
VF has leaked

Expected results:
VF should released on VM shutdown

Comment 1 Michael Burman 2017-04-27 08:00:15 UTC
VF released only on host reboot.

Comment 2 Michal Skrivanek 2017-04-28 09:03:24 UTC
Please clarify what do you mean by "leaked" and "released".

If you mean that the hsot device is detached from the host and not reattached on VM shutdown then this is by design

Comment 3 Michael Burman 2017-04-30 10:47:06 UTC
I mean that the host device is not reattached on VM shutdown as it designed with sr-iov 'passthorugh' vNICs. And can't be used by other VMs. 

If this is the design, Ok(although we not sure it's the best design), why it's not reattached back to the host on host device remove from the VM?(it's pretty bad). It should at least reattached back to the host, if the host device removed from the VM.
And it's not get reattached on VM remove as well..(which is pretty bad as well). 
Should be at least reattached back on host device remove/VM remove.

Comment 4 Tomas Jelinek 2017-05-04 09:57:04 UTC
(In reply to Michael Burman from comment #3)
> I mean that the host device is not reattached on VM shutdown as it designed
> with sr-iov 'passthorugh' vNICs. And can't be used by other VMs. 
> 
> If this is the design, Ok(although we not sure it's the best design), why
> it's not reattached back to the host on host device remove from the VM?(it's
> pretty bad). It should at least reattached back to the host, if the host
> device removed from the VM.
> And it's not get reattached on VM remove as well..(which is pretty bad as
> well). 
> Should be at least reattached back on host device remove/VM remove.

it is not reattached to the host since it is a risky operation. You are not able to use this device on the host, but you should still be able to use it in an another VM. Is this the case? Are you able to attach the device to an another VM?

Comment 5 Dan Kenigsberg 2017-05-16 10:53:52 UTC
Now that we no longer reattach devices to host, we should at least provide a simple tool to let a local admin (that knows his hardware and drivers) to explicitly request that.

something like

  vdsm-tool reattach-detached-devices

Comment 6 Yaniv Kaul 2018-01-11 13:17:24 UTC
Dan, so is the state it is still unavailable to other VMs? How is that a RFE?

Comment 7 Dan Kenigsberg 2018-04-29 15:46:28 UTC
The devices are available for VMs, but not for the host itself.

Comment 8 Ryan Barry 2018-11-14 11:25:32 UTC
This will not make it in a reasonable time. Please re-open if you still feel this should be fixed

Comment 9 Michael Burman 2019-04-15 04:43:04 UTC
*** Bug 1672252 has been marked as a duplicate of this bug. ***