On Tue, Jun 20, 2017 at 04:14:12PM +0200, Paolo Bonzini wrote: > We have four policies: > > 1) LUN0 only > > 2) higher LUNs in lower targets win > > 3) LUN0 in all targets win > > 4) LUNs up to N and bootable ones in all targets win > > (2) causes regressions so it's worse. (3) and (4) don't. > > Because the common case is "not enough disks to trigger the issue", I > think it's appealing to have no limit on LUNs (3); the disadvantage is > the parallel multi-controller case. > > The "and bootable ones" clause in (4) is nifty, and even "LUN0 and > bootable nonzero LUNs" could be a good compromise. However, I'm not > sure which higher-level management tools (OpenStack, oVirt, Virtuozzo) > let you customize the boot order and how easily.
Alas, none of these options seem appealing to me. If virtio-scsi didn't need to allocate any space in the f-segment, does this problem go away in practice? -Kevin _______________________________________________ SeaBIOS mailing list SeaBIOS@seabios.org https://mail.coreboot.org/mailman/listinfo/seabios
