How to discard changes?

Discussion in 'Virtual PC' started by VanguardLH, Dec 23, 2008.

  1. VanguardLH

    VanguardLH Guest

    I have the Undo disk option enabled. I want to use the guest OS as a
    test platform for unknown and untrusted software. When I'm done
    trialing the software, I want to discard any changes it made. In VMWare
    Server, I simply reverted to a baseline snapshot of the guest VM. In
    VirtualPC 2007, the only thing that I see that comes close to is close
    the VM using the "Turn off and discard changes" action (which also
    disabled the "Commit changes to the virtual disk" option). Yet, I
    recall seeing in its help somewhere a mention that turning off the VM
    was like yanking the power cord to the host and could cause file system
    corruption. So once I'm done playing with some software in the VM, how
    to I wipe the virtual hard disk back to the state it was in before I
    installed that experimental software?
    VanguardLH, Dec 23, 2008
    1. Advertisements

  2. VanguardLH

    Bo Berglund Guest

    When you close the machine normally, at the end there will be a
    dialogue asking you if you want to:
    - Commit changes to the hard disk
    - Save the changes for later
    - Discard the changes

    Select Discard and you will lose all changes since you enabled the
    undo disk.
    Bo Berglund, Dec 23, 2008
    1. Advertisements

  3. VanguardLH

    SaGS Guest

    As long as you enabled undo disks, "Turn off and delete changes" is OK. I
    use it all the time and never had any problem.

    Yes, some virtual hd could have file system problems but that's the undo
    disk. This undo disk is a file on the host separate from the original *.VHD,
    and the "Turn off and delete changes" does delete it completely. The
    original *.VHD was not touched at all, and this is the only one that remains
    and will be used the next time you start the virtual machine.

    PS: Sorry, I think I clicked a wrong button and so did not reply to the
    SaGS, Dec 23, 2008
  4. VanguardLH

    VanguardLH Guest

    The close options presented are:

    What do you want the virtual machine to do?
    - Save state and save changes.
    - Shutdown Windows XP and save changes.
    - Turn off and save changes.
    - Turn off and delete changes. (*)

    and a separation option:

    Commit changes to the virtual hard disk.

    (*) This choice deselects and disables the "Commit changes to the
    virtual hard disk" option.

    So I can stop a VM session and save changes so they are there for the
    next VM session; i.e., when I need to get back to trialing the software,
    it will still be there. However, I must deselect the "Commit changes"
    option to ensure that the undo disk changes are not applied to the
    virtual hard disk. That way, eventually I can toss the undo disk's
    changes so remove all changes that were made to the VM.

    Eventually I want to discard all changes and get back to my baseline VM.
    The only option that seems appropriate is "Turn off and delete changes".
    This deselects and disables the "Commit changes" option. So apparently
    I am expected to power off the VM (instead of shutting it down) and not
    commit any changes (and not save state as per the other choices).

    My concern is that the help mentions somewhere that "turning off" could
    result in file system corruption in the VM yet that is the only close
    option that I can see that will not save state and discard any changes.

    As a side issue, I sure wish that I could default the "Commit changes"
    option to off (deselected) instead of enabled (selected) for the first
    three close options. I don't want to remember on every close to NOT
    commit the changes because eventually I'll be discarding them.
    VanguardLH, Dec 23, 2008
  5. In this case your concern is unfounded. the changes occur when you
    *start* the virtual machine. When you shut off the VM, the only thing
    that is discarded are those changes after you started the VM. As far
    as the base VHD is concerned, it was never turned on.
    You can. Once you select this and turn off the VM, the next time you
    do this, it will remember the last state.
    Steve Jain [MVP], Dec 23, 2008
  6. VanguardLH

    VanguardLH Guest

    That's what I concluded but wanted some validation that I made the right
    choice. The "Commit changes" option can be disabled for the first three
    close options so that I'm only saving the VM's state between VM sessions
    but not altering the state of the .vhd file (the changes stay on the
    undo disk). The last close option of "Turn off and discard changes" was
    the only one that looked like it would discard the undo disk and the
    changes recorded there. Thanks for the feedback. Looks like I'm doing
    it the right way. Just wish the options were more clearly written.

    As a side issue, I sure wish that I could default the "Commit changes"
    option to off (deselected) instead of enabled (selected) for the first
    three close options. I don't want to remember on every close to NOT
    commit the changes because eventually I'll be discarding them. While
    testing software in the VM, I need to save state between VM sessions
    until I get done trialing the software. Everytime I close and save
    state, I have to remember to deselect the "Commit changes" option. If I
    forget just once, I'm screwed because my .vhd will then get polluted
    with the test software.

    The best that I've come up with to emulate VMWare's snapshot feature is
    to copy the folder containing the VM's files (with no changes so no undo
    disk recordings) but occupies a LOT of disk space. I elected to create
    a fixed-size VHD for performance reasons instead of a dynamically
    growing VHD. The VHD is 16GB in size, so copying the folder with the
    VM's files as a backup to provide an emulated snapshot (by copying it
    back) would occupy another 16GB. I don't even want to waste the disk
    space to backup the VHDs (if I lose them, I'll rebuild the guest OS from

    The defaults has Microsoft assuming that you usually want to move your
    VM forward with additional changes but that's contradictory to having
    undo disks. The undo disks only work if you do NOT commit changes, so
    the "Commit changes" option should be off be default. Then when the
    user actually decides to move forward and keep the new software would
    they then commit the changes.

    I've hunted around in the registry but haven't yet found a setting that
    configures the default state for the "Commit changes" option.
    VanguardLH, Dec 23, 2008
  7. alternately, you could use differencing disks instead then. Make your
    base VHD read-only and then create as many child VMs and VHDs off it
    as you like. The base never changes, and you can do whatever you want
    in the children without affecting the base image.
    Steve Jain [MVP], Dec 23, 2008
  8. This is in the .vmc file, not the Registry. Look for the section:

    <prompt type="boolean">true</prompt>
    <action type="integer">4</action>
    <enable type="boolean">true</enable>
    <enable type="boolean">true</enable>
    <enable type="boolean">true</enable>
    <choice type="integer">3</choice>
    <commit type="boolean">false</commit>
    what you want is the last couple lines, last_shutdown, choice 3, false
    commit, etc
    Steve Jain [MVP], Dec 23, 2008
  9. VanguardLH

    Bo Berglund Guest

    A suggestion:
    - Enable undo disks (you have)
    - Set the VHD disk file as *readonly* in the host file system

    Now I think that even if you forget to uncheck the commit checkbox the
    commit will fail because the VHD file is readonly.
    With undo disks enabled the VHD file is *only* written to if you have
    selected to commit changes, never otherwise. So running with a
    readonly VHD file should work just fine.
    It is very similar to using differencing disks in several guests all
    using the original (readonly) VHD as the parent.
    Bo Berglund, Dec 23, 2008
  10. VanguardLH

    VanguardLH Guest

    Thanks for the heads up. I tested this and it does appear to be a
    sticky setting. Great! I just know that one day I'll get busy or
    interrupted and forget to turn off that option and end up polluting my
    baseline VHD.

    By the way, in the VPC console when I right-click on a VM, one of the
    entries is "Delete saved state". I'm guessing that also gets rid of the
    changes that got recorded on the undo disk and I'd be back to the
    baseline VHD (and without have to startup the VHD to then close it to
    get the close options to discard changes).
    VanguardLH, Dec 23, 2008
  11. VanguardLH

    VanguardLH Guest

    I just started getting to the help topics and online articles discussing
    the differencing disks and it looks quite interesting. Might be what I
    like instead of having to remember to not commit changes. Need to do
    some more reading. Thanks for the heads up.
    VanguardLH, Dec 23, 2008
  12. VanguardLH

    VanguardLH Guest

    Per your other post stating that the "Commit changes" option is sticky,
    and testing to see that it sticks, it appears the Boolean state in the
    ..vmc reflects what was my last choice for that option. So if I deselect
    the "Commit changes" option then this Boolean value in the .vmc file
    gets set to 'false' (and what I see now after turning off the option and
    checking that it was sticky). Thanks again.
    VanguardLH, Dec 23, 2008
  13. VanguardLH

    VanguardLH Guest

    That's an idea. I do like the concept of differencing disks to run
    guests using those so the baseline .vhd file doesn't get altered. I'll
    have to experiment with differencing disks to see if that setup works
    the way that I like. Thanks.
    VanguardLH, Dec 23, 2008
  14. VanguardLH

    Bo Berglund Guest

    I think that "saved state" really refers to the state the virtual
    machine was in when it was "put on standby" instead of being fully
    shut down.
    This state is recorded in a file different from the VHD and the undo
    disk file and basically contains the current state of the machine's
    RAM and with all running programs and open documents and such (a bit
    like the hibernation file on a physical PC).

    Deleting this does not affect the undo disk, it just gets rid of all
    that is in memory and was not saved. The undo disk holds whatever was
    saved to disk in the sessions since the undo disk was activated.
    Bo Berglund, Dec 23, 2008
  15. VanguardLH

    VanguardLH Guest

    Okay, another question. Can I do the following:

    - Create one VM, called "Windows XP Pro (reference)", that is the
    reference or baseline VM that contains the clean install of the guest OS
    (and any updates that I apply for it). That VM would only be used to
    update the guest OS (i.e., Windows Updates which are configured to
    notify only so I choose when and if to update).

    - Another VM, called "Windows XP Pro (test)", that is used for testing
    unknown or untrusted software within that VM. It's virtual hard disk
    would be a differencing disk based on the reference VM's virtual disk.

    I could then keep the reference VM updated when needed or wanted but not
    touch it for doing software trials. The test VM would be where I trial
    the unknown or untrusted software. The test VM would use a differencing
    disk using the reference VM's disk. This assumes a differencing disk
    can be based off a virtual hard disk assigned to a different VM.

    Of course, I wouldn't be running the reference VM when I was running the
    test VM for two reasons. I assume the reference disk must be stable and
    unchanging for use by the differencing disk. However, if I apply
    updates to the reference disk, will the differencing disk continue to
    function or does it then get out of sync with the reference disk? If I
    do change the reference disk (to update that guest VM), does this
    invalidate the contents of the differencing disk for the other guest VM?
    Or are differencing disks to only be used within the same guest VM?
    VanguardLH, Dec 24, 2008
  16. If you make changes to the parent disk, you'll lose your child disks.
    What actually happens to the children really depends. In some cases,
    I've seen the child become unbootable and unusable, in other cases,
    I've seen it revert back to the parent's image.
    Never make changes to a parent image if you want to use the child
    disks connected to it.
    Steve Jain [MVP], Dec 24, 2008
  17. VanguardLH

    VanguardLH Guest

    Started the VM and went to the Windows desktop. Made a couple changes
    to sound events. Closed the VM and selected "Save state and save
    changes" with "Commit changes" unselected. The VM closed. I then
    right-clicked on the VM in the console and used "Delete saved state".
    The following warning appeared:

    You will lose any data not written to disk before the saved state was
    created, and you may corrupt your virtual hard disk.

    I clicked "Delete" to continue. The VM did not display the Windows
    desktop. Instead it started from a bootup point (BIOS notice, OS
    loads). When I logged in and checked the changes that I made to the
    sound events, and they were still present. So "Delete saved state" on
    the VM (when it was not running) got rid of the saved state (and
    required a bootup on starting the VM) but my changes were still there.

    VanguardLH, Dec 24, 2008
  18. VanguardLH

    VanguardLH Guest

    Okay, a bit more testing. I have Undo disk enabled. This creates a
    ..vud file that contains the changes. The guest's state, on closing it,
    gets saved into a .vsv file. While the guest is closed (not running),
    and when I use right-click "Delete saved state" on the guest, just the
    ..vsv file (saved state) got deleted. The .vud file (undo disk) was
    still there.
    VanguardLH, Dec 24, 2008
  19. VanguardLH

    VanguardLH Guest

    But it seems that I could delete the differencing hard disk from the
    child VM and create a new one based on the updated reference virtual
    hard disk. That wouldn't be too bad. I probably would only be updated
    the reference virtual disk a week or so after the monthly Patch Tuesday
    (to make sure that want them all).

    It even seems that I could create the reference VM with both a baseline
    virtual hard disk and undo disk to provide recovery in case an OS
    upgrade went haywire. Once I got it solidified, I'd commit the changes.
    Then I'd delete the differencing disk in the child VM and create a new
    on based on the update reference virtual hard disk.
    VanguardLH, Dec 24, 2008
  20. Deleting a saved state is like pulling the plug on a running system.
    Steve Jain [MVP], Dec 24, 2008
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.