Comment 16 for bug 1814832
Revision history for this message
| Oliver Kurth (okurth-1) wrote Re: [Bug 1814832] Re: Correct and/or improve handling of certain quiesced snapshot failures | #16 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
73416ba
(Get the code!)
I think this is good to go, and does not need any more additional testing, assuming you have applied the changes from the stable-
Thanks,
Oliver
_______
From: <email address hidden> <email address hidden> on behalf of Christian Ehrhardt <email address hidden>
Sent: Tuesday, April 9, 2019 11:10 PM
To: Oliver Kurth
Subject: [Bug 1814832] Re: Correct and/or improve handling of certain quiesced snapshot failures
@Oliver - any update on this testing?
That is the only one missing still to release this.
--
You received this bug notification because you are subscribed to the bug
report.
https:/
Title:
Correct and/or improve handling of certain quiesced snapshot failures
Status in open-vm-tools package in Ubuntu:
Fix Released
Status in open-vm-tools source package in Bionic:
Fix Committed
Status in open-vm-tools source package in Cosmic:
Fix Committed
Status in open-vm-tools package in Debian:
Fix Released
Bug description:
[Impact]
* Upstream identified an issue that can occur on aborted (or
due to communication issues while doing) quiesced snapshots.
* Backport the upstream changes as part of our work getting the latest
10.3.5 to the latest Ubuntu LTS (Bionic)
[Test Case]
* This is hard to test, but fortunately VMWare who have the right setup
for this tested our change from a PPA. I'll ask for that again on SRU.
Never the less I'll outline roughly what is needed to trigger [1]:
1. Use the host side interface to trigger a quiesced snapshot
2. this is the hard part - have communication failures between vmtools
(guest) and VMX (host) while this is ongoing.
3. From the Hosts POV the operation is aborted, but vmtools sends a
manifest eventually
4. Receiving this will make VMX reply a error (as it didn't wait for
anything like it)
5. Finally this broke the state machine and in subsequent cases vmtools
will not send a manifest again
* Further related fixes make sure vmtoolsd give up if VMX aborted the
snapshot [2] and another [3] makes sure manifests are always sent to
avoid any desync between VMX and vmtoolsd
[1]: https:/
[2]: https:/
[3]: https:/
[Regression Potential]
* This is quite a change to the snapshot handling, so in theory there a
regression has to be assumed. Due to a lack of testcases and expertise
on our side that was handed to VMWare itself who have a much wider
matrix of tests and setups to run them on.
This was tested and confirmed good (even before the change made
it upstream).
* Furthermore those kind of snapshots are relevant to those
who use them (and they most likely want the fix for reliability as you
could get into a state where no further snapshots were possible). But
OTOH the majority of users of the open-vm-tools package most likely
don't use the feature at all. Fortunately changes are local to only the
vmbackup functionality.
[Other Info]
* n/a
---
Customers may hit issues with quiesced snapshots under certain
circumstances. This is fixed in a branch forked from 10.3.5:
https:/
snapshot
A more detailed description of the issue can be found in the
individual commit messages.
Also filed at Debian: https:/
bin/bugreport
To manage notifications about this bug go to:
https:/