lib/server: allow migration of in-memory block backends #826
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
(N.B. Stacked on #816.)
Register in-memory block backends for lifecycle callouts and teach them to export and import their contents.
Truthfully, this may be somewhat overengineered. Today, in-memory storage backends are only used for the cloud-init drive, which Nexus always marks as read-only. Since the guest can never change the drive's contents, and #807 ensures that propolis-server migration targets always inherit their initial in-memory backend contents from their sources, it is technically legal for the backend just to return
Migrator::Empty
if it's read-only (and returnMigrator::NonMigratable
if it's writable). However, this makes the Propolis lib assume things about the way propolis-server drives migrations, which seemed like a layering violation, so this change just does what's needed to migrate the backend's current data in all cases.One downside of this approach is that the serialized backend contents show up in migration logs (as part of the giant blob logged in the destination's
device_state
function). It may make sense to adjust this logging so that the serialized device payloads are removed from this log message. See #825 for more thoughts on this. I think this change would be large enough that if pursued it should be in its own PR.Add a PHD test for the new migration behavior. This test works on Debian 11, Ubuntu 22.04, and Windows Server 2022. It's skipped on Alpine guests because (for reasons I don't yet understand) the test's use of
iflag=direct
on that OS isn't sufficient to get reads to hit the actual in-memory backend.Finally, tweak a few PHD bits:
Tests: new PHD variation with Alpine, Debian 11, Ubuntu, and WS2022 guests.
Fixes #301.