Red Hat Bugzilla – Bug 859024
PRD35 - [RFE] Provide confirmation prompt while deactivating a NIC
Last modified: 2016-02-10 14:52:24 EST
Description of problem:
Hot unplugging disks or nics which are used on guests is not good. Hot unpugging (by deactivating) disk which has mounted filesystem on the guest would lead to IO ERROR or the process going to D state which will cause performance.
We need to prevent accidental hot unplug by providing a confirmation prompt.
Robust way to implement this may be by using rhev-agentd to tell the RHEV-M that the guest doesn't have any mounted filesystems on the disk and it's safe to unplug. Only then unplug.
Closing old bugs. If this issue is still relevant/important in current version, please re-open the bug.
Hi, IHAC who's using RHEV 3.2 and is requesting this feature to be available.
For them, This is not good because, at the moment it immediately deactivates the disk which can be fatal for a VM.
We may need to look at a broader requirement to create a dialog box element that prompts for validation of actions, but provides an "opt out" for future messages of the same type. We see this need in Virt as well.
Arthur, do we have a BZ for this higher level requirement? I can create it and link the BZs if not.
(In reply to Scott Herold from comment #3)
> We may need to look at a broader requirement to create a dialog box element
> that prompts for validation of actions, but provides an "opt out" for future
> messages of the same type. We see this need in Virt as well.
> Arthur, do we have a BZ for this higher level requirement? I can create it
> and link the BZs if not.
Not that I'm aware of, you can go ahead and create one.
Resolution for https://bugzilla.redhat.com/show_bug.cgi?id=1038980 is to add a confirmation when deactivating disks I believe.
This meets the reporting customer's requirements for accidental deactivation of disks.
The title of this bz also mentions nics, so I would suggest this bugzilla now focuses on what is required for nic deactivation.
Some additional background from the customer, they are wanting to handle day to day operations of RHEV environment to less skilled operations team and therefore things need to be foolproof. Accidentally clicking on a deactivate button/option that does not give you any warning will lead to problems.
Customer contact has himself accidentally done this and can see his operations teams doing this more frequently.
What can we do to get this bugzilla further prioritised?
Customer would like to see something for RHEV3.5 if possible.
[not sure why I was assigned to this issue to begin with > assigning to nobody]
to my understanding, all we need here is a confirmation dialog for the relevant hotunplug disk / hotunplug nic actions. this should be very easy to do, I don't see any reason to not do it for 3.5 (this is not up to me though).
theoretically, a separate bug with a 'network' Whiteboard should be opened in order to track the hotunplug nic action, and this (storage) BZ should track only the hotunplug disk action, but since the fix for both issues is so trivial AFAIK, I assume that both actions can be taken care of by the storage team in the context of this BZ (again - this is not up to me - it is up to the storage team).
@Scott/Arthur - I think that we already discussed this before: I don't fully agree to the idea of "opting out" confirmation dialogs for potentially "destructive" operations: when I shift-delete (i.e. "delete forever") a file on my file-system, I don't have an option to opt-out the confirmation dialog that is associated with it, and I am not sure if I want one, actually.
IMO, an opt-out option for dialogs should exist only for dialogs in a "harmless" effect context, e.g. "tip of the day" when starting an application or similar.
In any case: Even if we will eventually decide to go with an "opt-out" option for dialogs such as the ones that are discussed in this BZ, we should do it in the scope of a separate BZ, as mentioned in Comment #3.
We already have a lot of confirmation dialogs in the application. I am not sure if we received any complaints on not having an opt-out option for them, but I think that adding a couple more of those without the opt-out option won't make a big difference in this sense, but will help tremendously for this customer (and others) to prevent future mistakes that ultimately lead to opening this BZ.
(In reply to Paul Dwyer from comment #5)
> Customer would like to see something for RHEV3.5 if possible.
needinfo'ing storage stakeholders for consideration.
(In reply to Einav Cohen from comment #7)
> (In reply to Paul Dwyer from comment #5)
> > Customer would like to see something for RHEV3.5 if possible.
> needinfo'ing storage stakeholders for consideration.
As confirmation window for deactivating a disk is already implemented in 3.4 (bug 1038980 ) for the storage flow, I don't think there is a need to introduce a broader requirement to create a dialog box element that prompts for validation of actions. So we only need a local treatment on the Network side.
Nir, for your review,
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.