I've come across a problem with virtualization and array names that I'd
like some feedback on.
I created a debian squeeze host for KVM, with md0 and md1 for /boot and
/ respectively. During the install, I told grub to install on each
device separately (using /dev/disk/by-id/ name). Everything's hunky dory
at this point.
Then I created a KVM guest, gave it direct access to 2 additional
drives, and created another raid1 array on them, controlled by the VM.
Everything was still hunky dory until I rebooted, at which point I
received the grub rescue prompt. I did the ls command, and saw that grub
was seeing 2 (md0) devices. Oops.
The first 2 drives contained arrays named host.0 and host.1. The second
2 drives contained an array named guest.0. By the (apparent) luck of the
draw, grub attempted to boot from the guest.0 array and appropriately
failed. The problem here stems from the fact that grub uses only the
device portion of the array name, ignoring the host name portion.
I proceeded to boot SystemRescueCD, and renamed the guest.0 array to
guest.7, which remedied the problem.
While multiple raid arrays on a single host with duplicate md device
names isn't possible, with virtualization it's clearly possible when a
guest machine handles its own software raid. So I'm wondering how grub
might do a better job of handling this situation.
Linux will automount raid partitions only if the raid flag is set. I do
not set the raid flag on the guest's raid partitions, which keeps the
host from starting the guest's array. The guest then starts the array
according to the contents of it's mdadm.conf file.
Is there some reason that grub identifies/recognizes arrays that do not
have the raid flag set? If not, perhaps grub should only "find" raid
arrays which have the raid flag set.
Or perhaps there's some other way in which grub can handle this scenario
(a strong possibility, as I'm still in the process of learning grub2).
TIA for any insights and feedback.
--
-Eric 'shubes'
_______________________________________________
Bug-grub mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/bug-grub
