> On Apr 29, 2020, at 12:27 PM, Michael S. Tsirkin <m...@redhat.com> wrote:
> 
> On Wed, Apr 29, 2020 at 06:54:52AM +0000, Ani Sinha wrote:
>> 
>> 
>>> On Apr 29, 2020, at 12:22 PM, Michael S. Tsirkin <m...@redhat.com> wrote:
>>> 
>>> On Wed, Apr 29, 2020 at 06:11:20AM +0000, Ani Sinha wrote:
>>>> 
>>>> 
>>>>> On Apr 29, 2020, at 10:58 AM, Michael S. Tsirkin <m...@redhat.com> wrote:
>>>>> 
>>>>> o if there's a need to disable
>>>>> just one of these, commit log needs to do a better job documenting the
>>>>> usecase.
>>>> 
>>>> The use case is simple. With this feature admins will be able to do what 
>>>> they were forced to do from Windows driver level but now at the bus level. 
>>>> Hence, 
>>>> (a) They need not have access to the guest VM to change or update windows 
>>>> driver registry settings. They can enable the same setting from admin 
>>>> management console without any access to VM.
>>>> (b) It is more robust. No need to mess with driver settings. Incorrect 
>>>> settings can brick guest OS. Also no guest specific knowhow required.
>>>> (c) It is more scalable since a single cluster wide setting can be used 
>>>> for all VM power ons and the management plane can take care of the rest 
>>>> automatically. No need to access individual VMs to enforce this.
>>>> (d) I am told that the driver level solution does not persist across a 
>>>> reboot. 
>>>> 
>>>> Ani
>>> 
>>> Looks like disabling both plug and unplug would also address these needs.
>> 
>> No the driver level solution does not prevent hot plugging of devices but 
>> blocks just hot unplugging. The solution I am proposing tries to do the same 
>> but from the bus/hypervisor level.
> 
> Why does the driver level solution need to prevent just hot unplugging?

Because it not fair to prevent end users from hot plugging new devices when it 
is the (accidental?) hot unplugging of existing devices which causes issues.
 
> 
> 
>> 
>>> -- 
>>> MST


Reply via email to