Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Implement facilities for handling unexpected physical removal of block devices #1082

Open
psivesely opened this issue Jul 24, 2015 · 0 comments
Open

Implement facilities for handling unexpected physical removal of block devices #1082

psivesely opened this issue Jul 24, 2015 · 0 comments
Labels
C: Xen help wanted This issue will probably not get done in a timely fashion without help from community contributors. P: major Priority: major. Between "default" and "critical" in severity.

Comments

@psivesely
Copy link

Referencing #1072, we should keep an eye out for adding this functionality, if Xen in the future develops monitoring facilities in libxl:

Currently (R3.0) device must be detached from VM before physically unplugging it. Xen toolstack used in R3.0 (libxl + libvirt) does not have any device monitoring mechanisms. If the device is physically removed, the toolstack will still think the device is present and connected (also some settings of xen block frontend and backend will not be cleaned up because of that). The only way to tell the toolstack that device is no longer connected, is to detach it from VM (action initiated by the user, through qubes manager or qvm-block, not by backend driver in response to disconnecting the device). But if the device is no longer there, such detach action would fail.

There is a way to manually clean that mess (basically reconnect the device using low level commands, and then properly detach it), but it isn't anything we want to use in any way. In R2 we had a nasty hack for that, because toolstack in 4.1 was even more primitive in this manner (it hadn't track on connected devices). But it isn't applicable to R3. The proper fix would be to implement device monitoring facilities in libxl, then use that API in libvirt. But this a lot work and probably won't happen anytime soon...

-- @marmarek
@marmarek marmarek mentioned this issue Aug 30, 2015
Closed
@marmarek marmarek added this to the Release 3.1 milestone Sep 1, 2015
@marmarek marmarek added enhancement help wanted This issue will probably not get done in a timely fashion without help from community contributors. C: Xen P: major Priority: major. Between "default" and "critical" in severity. labels Sep 1, 2015
@marmarek marmarek mentioned this issue Oct 10, 2015
Closed
@marmarek marmarek mentioned this issue Nov 14, 2015
Closed
@marmarek marmarek modified the milestones: Release 4.0, Release 3.1 Feb 8, 2016
@marmarek marmarek mentioned this issue Feb 9, 2016
Closed
andrewdavidwong added a commit that referenced this issue May 31, 2016
@andrewdavidwong
Track #1082
6513813
@marmarek marmarek changed the title Implement facilities for handling unexpected physical removal of USB block devices Implement facilities for handling unexpected physical removal of block devices Jul 27, 2017
marmarek added a commit to marmarek/qubes-linux-utils that referenced this issue Sep 12, 2017
@marmarek
udev: major cleanup in block devices handling
764b0f3 
1. Do not detach device forcefully when it's removed. This breaks
libvirt (which thinks the device is still there). After this change, it
is possible to detach device using libvirt, even if it was already
removed physically from backend domain (unless it is dom0 - in which
case it is still broken). So, this is partial fix for
QubesOS/qubes-issues#1082.

2. Do not trigger "change" udev event when only QubesDB state needs to
be updated - this leads to massive udev events queue, and heavy I/O
usage - for example scanning all LVM many times. In some cases it even
caused infinite event queue.

3. Do not use QUBES_EXPOSED udev property - it was needed a while back
before QubesDB, because concurrent xenstore accesses are expensive
(because of transactions). It isn't the problem on QubesDB.

4. Cache information about device-mapper, so it is possible to
reconstruct it at device remove - when the actual device cannot be
queried anymore. This is specifically about list of lower layer devices
used.

5. Allow excluding loop devices pointing at a file in directory marked
with ".qubes-exclude-block-devices" file. This is more generic than
hardcoding /var/lib/qubes.

QubesOS/qubes-issues#3084
Fixes QubesOS/qubes-issues#3073
QubesOS/qubes-issues#1082
@qubesos-bot qubesos-bot mentioned this issue Sep 12, 2017
Closed
@3hhh 3hhh mentioned this issue Jun 6, 2019
Closed
@marmarek marmarek mentioned this issue Oct 29, 2019
Closed
@andrewdavidwong andrewdavidwong removed this from the Release 4.2 milestone Aug 13, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
C: Xen help wanted This issue will probably not get done in a timely fashion without help from community contributors. P: major Priority: major. Between "default" and "critical" in severity.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@marmarek @psivesely @andrewdavidwong