https://bugzilla.novell.com/show_bug.cgi?id=848754
https://bugzilla.novell.com/show_bug.cgi?id=848754#c8
--- Comment #8 from Mike Latimer
The domU LVs are *never* mounted in the dom0 environment and rarely migrated from one dom0 to another, so maybe that's why this has always worked OK.
Yes, if you are careful, you should be able to get away with this. It is usually safer to ensure dom0 never has access to those devices in the first place.
For dir0, right now /etc/xen/vm/dir0 is using:
/dev/disk/by-id/scsi-2000b0804e0002142
...which is symlinked to ../../dm-3. I changed /etc/xen/vm/dir0 to use:
/dev/disk/by-id/dm-uuid-mpath-2000b0804e0002142
... which is also symlinked to ../../dm-3.
Right now, your udev is synchronized with mpio, so both the scsi-XXX and dm-uuid-mpath-XXX devices should link to ../../dm-3. The problem is that the scsi-XXX devices start out being linked to ../../sdX, and are later remapped to ./../dm-3. If LVM activates before they are remapped, you can have a problem (i.e. LVM activated on a single path, rather than the MPIO device).
I still had the same issue when I tried to start dir0, so I added the domU /dev/disk/by-id/dm-uuid-mpath-* names to the filter list in dom0:
filter = [ "a|/dev/disk/by-id/dm-uuid-.*mpath-.*|", "r|/dev/disk/by-id/dm-uuid-part2-mpath-2000b0804e0002142|", "r|/dev/disk/by-id/dm-uuid-part2-mpath-2000b0804df002142|", "r|/dev/disk/by-id/dm-uuid-part2-mpath-2000b0804e0002142|", "r/.*/" ]
The problem with the above filter is that rules are processed in order. As the first accept rule will match all the dm-uuid-.*-mpath-.* devices, they will be accepted and never rejected. Changing that accept to after the reject rules will accomplish what you need here. BTW - I usually recommend people use MPIO aliases to name their LUNs, rather than leave that up to LVM. If you do that, you can create a more simple LVM filter that will reject all LUNs that start with 'vm-*' (as an example). Either way should work though. I am still not sure if the boot failure is due to LVM being activated on dom0 or not. For the time being, please try your test again after changing the filter. When the guest still fails to boot, are you left in a working maintenance shell? If so, I'd like to get the output of lsscsi, pvscan, and lvscan from that shell...
What additional output from supportconfig do you need? What flags?
Simply running supportconfig (with no parameters) will provide everything I need. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.