PHD: add guest adapter for WS2022 #607
Conversation
The adapter assumes that - sysprep has been run such that the guest OS is generalized and, at first boot, its hostname will be set to "PHD-WINDOWS" - Cygwin is installed to C:\cygwin - the local administrator account is enabled with the appropriate password A suitable image is available on catacomb. This image passes `nproc_test`, but currently fails several other tests in ways that appear to be unrelated to the correctness of the adapter: - The Cygwin version in the test image doesn't include a `pciutils` package in-box, so the `lspci` lifecycle test doesn't work as expected. There are Windows ports of `pciutils` available that could resolve this, but a more flexible approach (which I will probably take in a future PR) is to allow tests to ask the framework what "flavor" of user space the current guest provides so that they can tailor their commands accordingly. - The Crucible tests unconditionally specify that the guest disk size should be 10 GiB, which is smaller than the guest image, which (unsurprisingly) leads to a very unhappy guest. This is a general problem with the way Crucible disk sizes work and will be fixed in a separate PR. Tests: local test run of the `nproc` smoke test with a WS2022 image.
| CommandSequenceEntry::WaitFor("Domain :"), | ||
| CommandSequenceEntry::WriteStr(""), | ||
| CommandSequenceEntry::WaitFor("Password:"), | ||
| CommandSequenceEntry::WriteStr("0xide#1Fan"), |
There was a problem hiding this comment.
If we're going to be encoding more expectations about image login credentials, it might make sense to have some top-level markdown doc listing them so that folks don't need to go fishing in the source for them?
There was a problem hiding this comment.
Good call, done in 40aed6a.
| impl GuestOs for WindowsServer2022 { | ||
| fn get_login_sequence(&self) -> CommandSequence { | ||
| CommandSequence(vec
| /// - The image has been generalized (by running `sysprep /generalize`) and is | ||
| /// configured so that on first boot it will skip the out-of-box experience | ||
| /// (OOBE) and initialize the local administrator account with the appropriate | ||
| /// password. See [MSDN's Windows Setup | ||
| /// documentation](https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/generalize?view=windows-11) | ||
| /// for more details. |
There was a problem hiding this comment.
this is lovely, thank you for expanding on it!
There was a problem hiding this comment.
My pleasure! One additional detail here (I mentioned this in DMs, but adding here as well for posterity) is that the (WIP) Windows image builder currently generates generalized images (so that we don't have to worry about any specialization conflicts if they're used as the read-only base images for multiple VMs), and I leveraged that here to create the test image I used to test this adapter. It might be possible to create an image that's technically been specialized already (so that Setup doesn't have to run and we don't have to wait for this reboot) but can still be reused across multiple VMs, but I'd have to do some research to figure out how.
The adapter assumes that
A suitable image is available on catacomb. This image passes
nproc_test, but currently fails several other tests in ways that appear to be unrelated to the correctness of the adapter:pciutilspackage in-box, so thelspcilifecycle test doesn't work as expected. There are Windows ports ofpciutilsavailable that could resolve this, but a more flexible approach (which I will probably take in a future PR) is to allow tests to ask the framework what "flavor" of user space the current guest provides so that they can tailor their commands accordingly.Tests: local test run of the
nprocsmoke test with a WS2022 image.Related to #601.