Live snapshot revert times increases linearly with snapshot age
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
QEMU |
Expired
|
Undecided
|
Unassigned |
Bug Description
The WineTestBot (https:/
Only some VMs are impacted. Based on libvirt's XML files the common point appears to be the presence of the following <timer> tags:
<clock offset='localtime'>
<timer name='rtc' tickpolicy=
<timer name='pit' tickpolicy=
<timer name='hpet' present='no'/>
</clock>
Where the unaffected VMs have the following clock definition instead:
<clock offset=
Yet shutting down the affected VMs, changing the clock definition, creating a live snapshot and trying to revert to it 6 months later results in slow revert times (>400 seconds).
Changing the tickpolicy to catchup for rtc and/or pit has no effect on the revert time (and unsurprisingly causes the clock to run fast in the guest).
To reproduce this problem do the following:
* Create a Windows VM (either 32 or 64 bits). This is known to happen with at least Windows 2000, XP, 2003, 2008 and 10.
* That VM will have the <timer> tags shown above, with the possible addition of an hypervclock timer.
* Shut down the VM.
* date -s "2014/04/01"
* Start the VM.
* Take a live snapshot.
* Shut down the VM.
* date -s "<your current date>"
* Revert to the live snapshot.
If the revert takes more than 2 minutes then there is a problem.
A workaround is to set track='guest' on the rtc timer. This makes the revert fast and may even be the correct solution. But why is it not the default or better documented?
* It setting track='wall' or omitting track, then the revert is slow and the clock in the guest is not updated.
* It setting track='guest' the revert is fast and the clock in the guest is not updated.
I found three past mentions of this issue but as far as I can tell none of them got anywhere:
* [Qemu-discuss] massive slowdown for reverts after given amount of time on any newer versions
https:/
* The above post references another one from 2011 wrt qemu 0.14:
https:/
* Comment #9 of Launchpad bug 1174654 matches this slow revert issue. However
the bug was really about another issue so this was not followed on.
https:/
I'm currently running into this issue with QEmu 2.1 but it looks like this bug has been there all along.
1:2.1+dfsg-
1:2.1+dfsg-
1:2.1+dfsg-
I'm unsure why clock time would affect snapshot revert, but one thing to note is that the general recommended timer settings for guest OS are different from what you have. virt-manager/ oVirt/OpenStack would all set:
<clock offset='localtime'> 'catchup' /> 'delay' />
<timer name='rtc' tickpolicy=
<timer name='pit' tickpolicy=
<timer name='hpet' present='no'/>
</clock>
in general for all guest OS, and if they have new enough QEMU (>= 2.0.0) + libvirt (>= 1.2.2), they'd go further and for Windows guests would set this
<clock offset='localtime'> 'catchup' /> 'delay' />
<timer name='rtc' tickpolicy=
<timer name='pit' tickpolicy=
<timer name='hpet' present='no'/>
<timer name='hypervclock' present='yes'/>
</clock>
This is fairly important to ensure reliable guest OS clock operation. It also avoids random BSOD on SMP guests from Windows 7 onwards.