Bug#567468: md homehost
Daniel Reurich <email@example.com> writes:
>> Could you please put forth the argument for why the homehost must
>> match, and why unconditional auto-assembly is not desirable?
>> Realistically, what problems are we protecting against?
> I can think of one or two.
> In the case of network boot, where the kernel and initrd served up via
> tftp, but the required filesystems are per host raid volumes served up
> ala ATAoverEthernet, iSCSI etc storage network. This could use the boot
> network device MAC or dhcp assigned hostname to as the homehost search
> paramater. This would of course require someway to tell mdadm how to
> obtain this homehost parameter. This could work well where different
> groups of hosts using different raid volumes for the root (or other)
> filesystems, each with a MAC group (first 3 or 4 MAC fields) is used to
> identify that groups homehost search parameter.
To get AoE or iSCSI working you need networking. That means dhcp will
already have run and the hostname be set.
> Another scenario, is a dual boot system that has separate raid volumes
> for the respective root filesystems, along with a separate initrd image
> for each OS. A system uuid stored in the initrd would work in this case
> for the homehost search parameter.
Or virtualization with raid in the virtual hosts. The host system will
see all the raids of the virtual systems but none of them should be