* S. J. van Harmelen > I have a storage server with an MD3000 attached to it. This server > runs the multipath-tools to create redundant paths: > > root@storage:~# multipath -ll > <snip> > xen (360019b9000d7e11000004485473faa94) dm-0 DELL ,MD3000 > [size=200G][features=0][hwhandler=0] > \_ round-robin 0 [prio=3][active] > \_ 1:0:0:3 sde 8:64 [active][ready] > \_ round-robin 0 [prio=0][enabled] > \_ 1:0:1:3 sdi 8:128 [active][ghost] > <snip> I think you need hwhandler = "1 rdac" for the MD3000 to be able to fail over properly. At least a colleague that have played with it told me so. > On the XenSource server I use a shared iSCSI storage so multiple > servers can access the same data so I can do live migrations. When I > add the storage XenSource creates a PV and then when I create a VM, > it creates LV's for each virtual harddisk. > > So far so good I guess, as the XenSource machine uses the multipathed > drive, right? You absolutely need to keep LVM (in dom0) from using /dev/sde or /dev/sdi as the PV (instead of /dev/mapper/xen). You can accomplish this with a filter line in lvm.conf: filter = [ "a|^/dev/mapper/xen$|", "r|.*|" ] Which means that a device node that is exactly «/dev/mapper/xen» is considered a valid PV candidate, all other devices are rejected. >From the email you sent with earlier pvscan output you got /dev/dm-0 as the active PV, with pvs you got /dev/sde (and with both you got I/O errors to the passive paths). It can't be relied upon that you'll get dm-0 (which is absolutely necessary if you want dm-multipath to serve any purpose) in the future unless you force LVM to only look for PVs in the multipath'ed block devices. > Now I would like to take snapshots of the whole PV so I can make > backups. My thoughts where to make a PV on /dev/mapper/xen that spans > the whole disk, and then create a single LV on it. You can only take snapshots of LVs, not PVs. And you would have to create a VG first with /dev/mapper/xen as a PV (you can't add LVs directly on PVs). But I think you've got the basic idea correct. :-) > If I then take the path to that single LV, say /dev/volumegroup/disk1 > as target for iSCSI, then the XenSsource server should only see that > LV as the shared iSCSI repository. > > But then XenSource wil create a PV and a couple of LV's in the > existing LV (created on the storage server and shared true iSCSI). > Could that create any problems or can I just do that? I see no reason why that wouldn't work. Try it and see? Inside the domU the Linux kernel won't know that its available block devices are really mapped to another LVM implementation that runs in dom0. LVM is probably clever enough to disregard that LV-containing-a-PV as a valid PV candidate, but if not the filter line in lvm.conf should handle it. Regards -- Tore Anderson -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
