This patch adds the following checks to xend: - Make sure a block device is not attached to more than one DomU at a time - Make sure a block device is not attached to a DomU if it is mounted in Dom0 - Make sure a block device exists before even trying to attach it - Make sure files specified with "file:" actually exist and have the necessary permissions This makes tests 11_block_attach and 12_block_attach pass. In order to check if a device is attached to another DomU, I search the /local/domain/0/device/vbd/*/*/physical-device nodes to see if any DomU had the device already. Although this is ugly, I think it''s the best way, so that we don''t depend on any xend internal state. Comments? Signed-off-by: Dan Smith <danms@us.ibm.com> -- Dan Smith IBM Linux Technology Center Open Hypervisor Team email: danms@us.ibm.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Wed, Nov 23, 2005 at 12:24:19PM -0800, Dan Smith wrote:> This patch adds the following checks to xend: > > - Make sure a block device is not attached to more than one DomU at a > time > - Make sure a block device is not attached to a DomU if it is mounted > in Dom0 > - Make sure a block device exists before even trying to attach it > - Make sure files specified with "file:" actually exist and have the > necessary permissions > > This makes tests 11_block_attach and 12_block_attach pass. > > In order to check if a device is attached to another DomU, I search > the /local/domain/0/device/vbd/*/*/physical-device nodes to see if any > DomU had the device already. Although this is ugly, I think it''s the > best way, so that we don''t depend on any xend internal state.Thanks for your patch Dan. Unfortunately, Xend is not the right place for these checks. We have to worry about device configuration even when it''s not performed through Xend -- the drivers will configure the device if you write to the store, even if you don''t go through Xend. With that in mind, these safety checks need to be lower down in the system. I''ve put them into the hotplug scripts (the physical devices support has been checked in, and support for loopback files is on its way). I''ve applied the fix to 12_block_attach. Cheers, Ewan. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
EM> Unfortunately, Xend is not the right place for these checks. We EM> have to worry about device configuration even when it''s not EM> performed through Xend -- the drivers will configure the device if EM> you write to the store, even if you don''t go through Xend. With EM> that in mind, these safety checks need to be lower down in the EM> system. I think the drivers should attach multiple DomUs to the same block device, if asked to do so. The bug description said that this functionality should be provided by the tools for special-purpose filesystems that can handle concurrent writers. It seems perfectly logical to me for the drivers to do what they''re told, and have the tools (whatever tools may be in use) provide the checks and protections necessary to help the user from shooting himself in the foot. Further, I think that pushing a bunch of checks into the hotplug scripts is less desirable, as it makes it harder to communicate good information back to the frontend tools. Right now, we just get a "failed" message instead of "device missing" or "device already in use" message. -- Dan Smith IBM Linux Technology Center Open Hypervisor Team email: danms@us.ibm.com _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Fri, Nov 25, 2005 at 03:55:37PM -0800, Dan Smith wrote:> > EM> Unfortunately, Xend is not the right place for these checks. We > EM> have to worry about device configuration even when it''s not > EM> performed through Xend -- the drivers will configure the device if > EM> you write to the store, even if you don''t go through Xend. With > EM> that in mind, these safety checks need to be lower down in the > EM> system. > > I think the drivers should attach multiple DomUs to the same block > device, if asked to do so. The bug description said that this > functionality should be provided by the tools for special-purpose > filesystems that can handle concurrent writers.My fix includes an override to the test. By setting the mode to w!, you get read-write access, with sharing allowed.> It seems perfectly > logical to me for the drivers to do what they''re told, and have the > tools (whatever tools may be in use) provide the checks and > protections necessary to help the user from shooting himself in the > foot.To a certain extent, yes, but on the other hand, what you do by doing that is require all tools to duplicate the same checks. In this case, the check is so important (filesystems are easily corrupted without it) that the check would definitely have to be included in every tool, so it is better to push it down nearer the drivers, where it can be shared.> Further, I think that pushing a bunch of checks into the hotplug > scripts is less desirable, as it makes it harder to communicate good > information back to the frontend tools. Right now, we just get a > "failed" message instead of "device missing" or "device already in > use" message.My changes today add support for a hotplug-error node, which includes a full error description. If you mount a filesystem in dom0 and then try to use the same as a device in a guest, you will get the message: Error: Device 2049 (vbd) could not be connected. Device /dev/VG_XenRT/LV0 is mounted in the privileged domain, and so cannot be mounted by a guest. which is a lot better than some of Xend''s other messages. Ewan. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel