Bug#439410: More questions about multipath for d-i (was: Bug#439410: Updated patch)
On Mon, Sep 03, 2007 at 03:55:32PM +0200, Jérémy Bobbio wrote:
> * Are you going to support this in the future?
> I am unsure if there is anyone having the necessary hardware to
> ensure that multipath is working correctly in the future. So I would
> feel a lot more comfortable in adding multipath support to d-i if you
> are willing to maintain it. :)
As time permits - of course.
> * Could installations on multipath be emulated?
> Is there any way to emulate an installation on multipath using
> qemu, virtualbox or a similar tool? waldi told me that dm-linear was
> one of the way to do so but I don't know how it would interact with
Several. You could work with losetup but this dosn't work
nicely at the moment. A much better solution is to use iSCSI -
once we support iSCSI in d-i we can easily test multipathing by
assigning the target a second ip-address.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=419408 has a patch
for iscsi support in the initramfs. Adding iscsistart to a udeb would be
the next step. You could then use the qemu host as the iSCSI target
and the quemu guest as the initiator (and supporting multipath over
iSCSI in lenny would be really a blast since this is very handy when it
comes to large clusters of virtual machines).
You should also be able to test this on any SATA system quiet easily
since this looks like scsi - you'd only have a single path to the device
then but that doesn't make a difference when it comes to the installer.
The important part is that you get the /dev/mapper/mpath* devices. You
might have to whitelist the SATA disk via:
in multipath.conf, but that should be about it.
> * Could you provide us with a test image?
> I'd like to have a feeling about the necessary steps to configure
> multipath. Could you provide us with a test image with your current
> achievements (especially if the above is true!).
There currently are no steps since 'multipath -l' in disk-detect.sh
detects the paths and offers /dev/mapper/mpath0 as a "regular" block
device. The rest of the code just makes sure partman doesn't treat the
/dev/mapper/mpath*-part* devices as lvm or crypto and that we create the
partition mappings via kpartx.
> As a last notice, for complete support, we will also need an update of
> the installer manual (and the appendix about preseeding).
Sure, but let me cleanup the rest of the patches and fix the
grub-install part first, I'll then also put an image somewhere.
I'm keeping track of the current status here: