CP-54459: Install to SW RAID #248
Conversation
|
Will upgrade and restore be handled in a separate PR? |
How did you verify that GRUB was accessing the data via the RAID device rather than just accessing it through one of the RAID members? |
|
|
I entered the grub command line and checked the output of |
|
Nice to see that XenServer is finally interested in this feature - we have an implementation that has been used by XCP-ng users for several years, so maybe we could synchronize? We never opened a PR because XS was not interested at the time, but now it looks like the time can be right. You may also be interested in #38 as a useful complement. |
We're not going to support this, aside from for one specific internal customer, it will not be available to the general user population. |
But then, especially if that's clearly not something on your roadmap, why spend time reimplementing something that's been in production on our side for more than 6 years? We'd be perfectly OK to, for example, get the non-interactive part in shape to be shared, and get the UI part behind a feature flag. |
GeraldEV
force-pushed
the
private/geralde/CP-54459
branch
from
0d418d9 to
fac602f
Compare
backend.py
Outdated
| seq.append(Task(removeBlockingVGs, As(ans, 'guest-disks'), [])) | ||
|
|
||
| if ans['swraid']: | ||
| seq.append(Task(setupSWRAIDDevice, A(ans, 'disk-label-suffix', 'physical-disks'), ['primary-disk'])) |
There was a problem hiding this comment.
This moved block was so that setupSWRAIDDevice could occur before partitionTargetDisk (which would otherwise be unhappy with a missing target device) and after removeBlockingVGs
GeraldEV
force-pushed
the
private/geralde/CP-54459
branch
from
fac602f to
7fdb932
Compare
|
I've pushed two new changes to complete the behaviour and address an issue:
|
GeraldEV
force-pushed
the
private/geralde/CP-54459
branch
from
7fdb932 to
3131143
Compare
GeraldEV
force-pushed
the
private/geralde/CP-54459
branch
from
3131143 to
983a1e3
Compare
Previously the filterCleanup was only ever called by filter with an empty list, but due to SWRAID changes; there's scope for it to be called 'properly' with cleanup operations. This revealed that the filterCleanup incorrectly assumed the arguments would be automatically unpacked from the tuples. Signed-off-by: Gerald Elder-Vass <gerald.elder-vass@cloud.com>
Signed-off-by: Gerald Elder-Vass <gerald.elder-vass@cloud.com>
Signed-off-by: Gerald Elder-Vass <gerald.elder-vass@cloud.com>
GeraldEV
force-pushed
the
private/geralde/CP-54459
branch
from
983a1e3 to
d2b7da1
Compare
GeraldEV
force-pushed
the
private/geralde/CP-54459
branch
from
d2b7da1 to
0297ad2
Compare
rosslagerwall
left a comment
rosslagerwall
left a comment
There was a problem hiding this comment.
This basically looks fine to me. A few minor comments.
Signed-off-by: Gerald Elder-Vass <gerald.elder-vass@cloud.com>
Signed-off-by: Gerald Elder-Vass <gerald.elder-vass@cloud.com>
Signed-off-by: Gerald Elder-Vass <gerald.elder-vass@cloud.com>
Signed-off-by: Gerald Elder-Vass <gerald.elder-vass@cloud.com>
GeraldEV
force-pushed
the
private/geralde/CP-54459
branch
from
0297ad2 to
399aa34
Compare
5 participants
Create a SW RAID device using mdadm before installation from specified devices
SW RAID installation only available via answerfile and not included in the answerfile documentation as this feature is not designed for wide support - it was specifically requested by an internal customer
UEFI boot does not understand SW RAID and therefore we need to add an EFI boot entry for each physical disk that makes up the SW RAID device. There is a known bug that the GPT header for the second disk in the SW RAID is not correctly populated and therefore its boot entry is invalid - this will be triaged & addressed in a later PR
GRUB already understands Linux SW RAID devices (via its mdraid1x module) which does not need to be explicitly loaded for GRUB to see the SW RAID device - this was verified via the GRUB command line
udev automatically assembles the SW RAID device when starting