-
Notifications
You must be signed in to change notification settings - Fork 259
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
wclayer: Work around Windows bug when expanding sandbox size #718
Conversation
ba4ca33
to
164f6a7
Compare
This change works around a bug in Windows where a sandbox VHDX that has been resized cannot be successfully mounted. This is due to a failure in the path that resizes the NTFS volume inside the VHDX during the sandbox mount process. To work around this, manually expand the volume in the wclayer package just after making the call to expand the VHDX. This change hurts the performance of the resize operation on affected Windows hosts (19H1 and prerelease versions of Vb) and should be reverted once the Windows bug has been fixed and is widely deployed.
164f6a7
to
d2042e6
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Can you open a work item to revert this pending some future when the Windows fix is released.
Can we merge this? Can someone work to get this integrated into Moby? |
@jstarks - I can work on getting this integrated into Moby once the merge goes through. |
@vikramhh - Can you update vendor and run CI? This will be more code changes than just this PR in the vendor update so want to make sure we didnt regress anything. If you find anything I will look asap |
Among other things, this is required to pull in microsoft/hcsshim#718 which should take care of multiple issues reported to us. Signed-off-by: Vikram bir Singh <[email protected]>
Among other things, this is required to pull in microsoft/hcsshim#718 which should take care of multiple issues reported to us. Also fixes microsoft/hcsshim#737 which was caught by checks while attempting to bump up hcsshim version. Modifies TestRunAttachFailedNoLeak to do case-insensitive comparison to fix a failure on RS1. Signed-off-by: Vikram bir Singh <[email protected]>
Among other things, this is required to pull in microsoft/hcsshim#718 Also fixes microsoft/hcsshim#737 which was caught by checks while attempting to bump up hcsshim version. Signed-off-by: Vikram bir Singh <[email protected]>
Among other things, this is required to pull in microsoft/hcsshim#718 Also fixes microsoft/hcsshim#737 which was caught by checks while attempting to bump up hcsshim version. Signed-off-by: Vikram bir Singh <[email protected]> Upstream-commit: a7b6c3f0bf5d10c6227a29bac7dd46b9a7a779bc Component: engine
Among other things, this is required to pull in microsoft/hcsshim#718 Also fixes microsoft/hcsshim#737 which was caught by checks while attempting to bump up hcsshim version. Signed-off-by: Vikram bir Singh <[email protected]> (cherry picked from commit a7b6c3f) Signed-off-by: Sebastiaan van Stijn <[email protected]>
Does anyone have an ETA on the Windows fix? I just hit this with Docker for Windows (19.03.5) running on Windows 10 1909 (18363.476) |
full diff: https://2226e083fc390003ae5aa8325c3c92789afa0e7a...b3f49c06ffaeef24d09c6c08ec8ec8425a0303e2 includes: - microsoft/hcsshim#718 wclayer: Work around Windows bug when expanding sandbox size - fixes microsoft/hcsshim#708 Windows Host Compute Service bug breaks docker (and other) sandboxes bigger than 20G on Windows 1903 - fixes microsoft/hcsshim#624The hcsshim on Windows 10 1903 always fails to build Docker image - fixes/addresses docker/for-win#3884 An error occurred while attempting to build Docker image (especially this comment and the next comments after: docker/for-win#3884 (comment)) - fixes/addresses docker/for-win#4100 Windows 1903 fails when storage-opt used - fixes moby/moby#36831 hcsshim::PrepareLayer failed in Win32: The parameter is incorrect (moby/moby#36831 (comment)) - fixes Stannieman/audacity-with-asio-builder#5 Docker won't build container - fixes MicrosoftDocs/visualstudio-docs#3523 Error when running build with storage-opts set - fixes moby/moby#39524 Docker build windows 19.03 --storage-opt size>20G Note that this is a temporary workaround for a bug in the platform, and will be reverted once that is addressed: - microsoft/hcsshim#721 Revert 718 when Windows 19H1 has expand sandbox fix Signed-off-by: Sebastiaan van Stijn <[email protected]>
full diff: https://2226e083fc390003ae5aa8325c3c92789afa0e7a...b3f49c06ffaeef24d09c6c08ec8ec8425a0303e2 includes: - microsoft/hcsshim#718 wclayer: Work around Windows bug when expanding sandbox size - fixes microsoft/hcsshim#708 Windows Host Compute Service bug breaks docker (and other) sandboxes bigger than 20G on Windows 1903 - fixes microsoft/hcsshim#624The hcsshim on Windows 10 1903 always fails to build Docker image - fixes/addresses docker/for-win#3884 An error occurred while attempting to build Docker image (especially this comment and the next comments after: docker/for-win#3884 (comment)) - fixes/addresses docker/for-win#4100 Windows 1903 fails when storage-opt used - fixes moby/moby#36831 hcsshim::PrepareLayer failed in Win32: The parameter is incorrect (moby/moby#36831 (comment)) - fixes Stannieman/audacity-with-asio-builder#5 Docker won't build container - fixes MicrosoftDocs/visualstudio-docs#3523 Error when running build with storage-opts set - fixes moby/moby#39524 Docker build windows 19.03 --storage-opt size>20G Note that this is a temporary workaround for a bug in the platform, and will be reverted once that is addressed: - microsoft/hcsshim#721 Revert 718 when Windows 19H1 has expand sandbox fix Signed-off-by: Sebastiaan van Stijn <[email protected]> Upstream-commit: dff269b5e4b8dc86d12116ac5dff9caca49593d9 Component: cli
Among other things, this is required to pull in microsoft/hcsshim#718 Also fixes microsoft/hcsshim#737 which was caught by checks while attempting to bump up hcsshim version. Signed-off-by: Vikram bir Singh <[email protected]> (cherry picked from commit a7b6c3f0bf5d10c6227a29bac7dd46b9a7a779bc) Signed-off-by: Sebastiaan van Stijn <[email protected]> Upstream-commit: e2f226b5b41c958fa518f677eb213eb1462f90a8 Component: engine
full diff: https://2226e083fc390003ae5aa8325c3c92789afa0e7a...b3f49c06ffaeef24d09c6c08ec8ec8425a0303e2 includes: - microsoft/hcsshim#718 wclayer: Work around Windows bug when expanding sandbox size - fixes microsoft/hcsshim#708 Windows Host Compute Service bug breaks docker (and other) sandboxes bigger than 20G on Windows 1903 - fixes microsoft/hcsshim#624The hcsshim on Windows 10 1903 always fails to build Docker image - fixes/addresses docker/for-win#3884 An error occurred while attempting to build Docker image (especially this comment and the next comments after: docker/for-win#3884 (comment)) - fixes/addresses docker/for-win#4100 Windows 1903 fails when storage-opt used - fixes moby/moby#36831 hcsshim::PrepareLayer failed in Win32: The parameter is incorrect (moby/moby#36831 (comment)) - fixes Stannieman/audacity-with-asio-builder#5 Docker won't build container - fixes MicrosoftDocs/visualstudio-docs#3523 Error when running build with storage-opts set - fixes moby/moby#39524 Docker build windows 19.03 --storage-opt size>20G Note that this is a temporary workaround for a bug in the platform, and will be reverted once that is addressed: - microsoft/hcsshim#721 Revert 718 when Windows 19H1 has expand sandbox fix Signed-off-by: Sebastiaan van Stijn <[email protected]>
wclayer: Work around Windows bug when expanding sandbox size
This change works around a bug in Windows where a sandbox VHDX that has
been resized cannot be successfully mounted. This is due to a failure in
the path that resizes the NTFS volume inside the VHDX during the sandbox
mount process. To work around this, manually expand the volume in the
wclayer package just after making the call to expand the VHDX.
This change hurts the performance of the resize operation on affected
Windows hosts (19H1 and prerelease versions of Vb) and should be
reverted once the Windows bug has been fixed and is widely deployed.
This should provide a workaround for #708.