Comment 3 for bug 1178721

https://help.ubuntu.com/12.10/serverguide/multipath-devices.html

You cannot have a default LVM config co-exist with multipath. They will
race to grab the SD device for map creation and whoever gets there first wins;
they both use device mapper. LVM is configured using UDEV so it's the
first pass, multipath in run by legacy rc script.

You must configure LVM to blacklist all SD devices.
Then, you must configure LVM to use allow the disks necessary for the
root volume using the UDEV names e.g. /dev/disk/by-id

SD names are never deterministic, sorry, that's what udev us for.

When the multipath volume is not root, you can easily test the config
per the documentation.

Any time a change is made to either multipath.conf or lvm.conf, the initrd
must be updated; also in the documentation. Multipath usually runs last, so if
you didn't push the lvm blacklist to the ramdisk, by the time multipath runs there's
nothing left for it to attach to.

Your "virtual multipath" is bogus, there's nothing that will arbitrate write
ordering, the block names aren't deterministic, and they never can be because
they don't have make/model/serial# which udev uses to create unique names.
You could easily "multipath" your root disk + a MP leg and be left with
swiss cheese based on scan ordering or hotplug events.

If you remove LVM from the stack and follow the directions for properly
propagating multipath to the ramdisk, it will work. Start small, then add an
additional layer of complexity.

There does not exist a tool which integrates the deployment of LVM + multipath
anywhere, you have to understand both and configure by hand. It is challenging
to deploy an LVM config that co-exits with multipath. Good luck.