Differential data not carrying over on resize up

Bug #1421707 reported by Ben Roble
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Compute (nova)
Fix Released
Low
John Garbutt

Bug Description

The differential data (data committed to the disk after the initial snapshot is created, but before the VM is shutdown) does not seem to be carried over on resizes up on standard instances. This can be tested by doing the following:

1. Create a cronjob that writes the time to a log file once every minute (* * * * * date >> /root/resize-test.log).
2. Resize the server up.
3. Examine the log file after the resize is complete, then revert the resize.
4. Compare it with the log file on the source after the revert is complete.

Data from the log file in one of my tests:
Destination (post-resize, pre-revert):

Sat Jan 31 12:10:01 UTC 2015
Sat Jan 31 12:11:01 UTC 2015
Sat Jan 31 12:12:01 UTC 2015
Sat Jan 31 12:13:01 UTC 2015
Sat Jan 31 12:14:01 UTC 2015
Sat Jan 31 12:15:01 UTC 2015
Sat Jan 31 12:16:01 UTC 2015
Sat Jan 31 12:17:01 UTC 2015
Sat Jan 31 12:18:01 UTC 2015
Sat Jan 31 12:19:01 UTC 2015
Sat Jan 31 12:25:01 UTC 2015
Sat Jan 31 12:26:01 UTC 2015
Sat Jan 31 12:27:01 UTC 2015
Sat Jan 31 12:28:01 UTC 2015
Sat Jan 31 12:29:01 UTC 2015
Sat Jan 31 12:30:01 UTC 2015
Sat Jan 31 12:31:01 UTC 2015
Sat Jan 31 12:32:01 UTC 2015
Sat Jan 31 12:33:01 UTC 2015
Sat Jan 31 12:34:01 UTC 2015

Source (post-resize, post-revert):

Sat Jan 31 12:04:01 UTC 2015
Sat Jan 31 12:05:01 UTC 2015
Sat Jan 31 12:06:01 UTC 2015
Sat Jan 31 12:07:01 UTC 2015
Sat Jan 31 12:08:01 UTC 2015
Sat Jan 31 12:09:01 UTC 2015
Sat Jan 31 12:10:01 UTC 2015
Sat Jan 31 12:11:01 UTC 2015
Sat Jan 31 12:12:01 UTC 2015
Sat Jan 31 12:13:01 UTC 2015
Sat Jan 31 12:14:01 UTC 2015
Sat Jan 31 12:15:01 UTC 2015
Sat Jan 31 12:16:01 UTC 2015
Sat Jan 31 12:17:01 UTC 2015
Sat Jan 31 12:18:01 UTC 2015
Sat Jan 31 12:19:01 UTC 2015
Sat Jan 31 12:20:01 UTC 2015 <-
Sat Jan 31 12:21:01 UTC 2015 <- 3 minutes worth of logs that didn't get copied over.
Sat Jan 31 12:22:01 UTC 2015 <-
Sat Jan 31 12:38:01 UTC 2015

Another way to make this bug obvious is to write multiple GB of data during the resize up process and notice how it is entirely lost when the resize completes.

Tags: xenserver
Ben Roble (ben-roble)
Changed in nova:
assignee: nobody → Ben Roble (ben-roble)
Changed in nova:
importance: Undecided → Low
status: New → Confirmed
Ben Roble (ben-roble)
tags: added: xenserver
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to nova (master)

Fix proposed to branch: master
Review: https://review.openstack.org/155879

Changed in nova:
status: Confirmed → In Progress
Changed in nova:
assignee: Ben Roble (ben-roble) → John Garbutt (johngarbutt)
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to nova (master)

Reviewed: https://review.openstack.org/155879
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=1a56eccfa74aa0ed4bf1edbe4fceeba0c2b2d323
Submitter: Jenkins
Branch: master

commit 1a56eccfa74aa0ed4bf1edbe4fceeba0c2b2d323
Author: Ben Roble <email address hidden>
Date: Wed Feb 11 22:52:34 2015 -0500

    XenAPI: Fix data loss on resize up

    Resize up does not copy all data to the destination if data is written
    between the start of the resize and the shutdown of the instance.

    It seems we copy only the empty snapshot marker VDI instead of the VDI
    that the VM keeps writing to during the resize operation. This fix
    changes resize up behavior to copy the correct VDI.

    Change-Id: I5eebdfaaa82481726ba6ce2a946773b6ea503905
    Co-Authored-By: John Garbutt <email address hidden>
    Closes-Bug: #1421707

Changed in nova:
status: In Progress → Fix Committed
Thierry Carrez (ttx)
Changed in nova:
milestone: none → kilo-3
status: Fix Committed → Fix Released
Thierry Carrez (ttx)
Changed in nova:
milestone: kilo-3 → 2015.1.0
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.