>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?

>Bo Berglund wrote:
>
>> On Tue, 23 Dec 2008 05:06:23 -0600, VanguardLH <(email address - cut out)> wrote:
>>
>>>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?
>>
>> 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.
>
>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.

>SaGS wrote:
>
>> "VanguardLH" <(email address - cut out)> wrote in message
>> news:giqgn7$id0$(email address - cut out)...
>>
>>>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?
>>
>> 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
>> group.
>
>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
>scratch).
>
>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.

>
>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.

>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?

> On Tue, 23 Dec 2008 05:06:23 -0600, VanguardLH <(email address - cut out)> wrote:
>
>>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?
>
> 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.

> "VanguardLH" <(email address - cut out)> wrote in message
> news:giqgn7$id0$(email address - cut out)...
>
>>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?
>
> 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
> group.

>VanguardLH wrote:
>
>> Steve Jain [MVP] wrote:
>>>
>>> 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.
>>
>> 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.
>
>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?

>>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.
>
> You can. Once you select this and turn off the VM, the next time you
> do this, it will remember the last state.

> On Tue, 23 Dec 2008 16:22:09 -0600, VanguardLH <(email address - cut out)> wrote:
>
>>SaGS wrote:
>>
>>> "VanguardLH" <(email address - cut out)> wrote in message
>>> news:giqgn7$id0$(email address - cut out)...
>>>
>>>>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?
>>>
>>> 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
>>> group.
>>
>>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
>>scratch).
>>
>>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.
>
> 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.

> On Tue, 23 Dec 2008 16:22:09 -0600, VanguardLH <(email address - cut out)> wrote:
>
>>
>>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.
>
> This is in the .vmc file, not the Registry. Look for the section:
>
> <shutdown>
> <prompt type="boolean">true</prompt>
> <quit>
> <action type="integer">4</action>
> <was_running
> type="boolean">false</was_running>
> </quit>
> <save>
> <enable type="boolean">true</enable>
> </save>
> <shutdown>
> <enable type="boolean">true</enable>
> </shutdown>
> <turn_off>
> <enable type="boolean">true</enable>
> </turn_off>
> <last_shutdown>
> <choice type="integer">3</choice>
> <commit type="boolean">false</commit>
> </last_shutdown>
> </shutdown>
> ****
> what you want is the last couple lines, last_shutdown, choice 3, false
> commit, etc

> On Tue, 23 Dec 2008 16:22:09 -0600, VanguardLH <(email address - cut out)> wrote:
>
>>SaGS wrote:
>>
>>
>>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.
>>
> 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.

> Steve Jain [MVP] wrote:
>>
>> 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.
>
> 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 wrote:
>
>> Bo Berglund wrote:
>>
>>> On Tue, 23 Dec 2008 17:47:49 -0600, VanguardLH <(email address - cut out)> wrote:
>>>
>>>>Steve Jain [MVP] wrote:
>>>>
>>>>>>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.
>>>>>
>>>>> You can. Once you select this and turn off the VM, the next time you
>>>>> do this, it will remember the last state.
>>>>
>>>>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).
>>>
>>> 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.
>>
>> 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.
>>
>> Thanks.
>
>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.

>Steve Jain [MVP] wrote:
>
>> On Tue, 23 Dec 2008 18:05:23 -0600, VanguardLH <(email address - cut out)> wrote:
>>
>>>VanguardLH wrote:
>>>
>>>> Steve Jain [MVP] wrote:
>>>>>
>>>>> 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.
>>>>
>>>> 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.
>>>
>>>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?
>>
>> 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.
>
>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.

> On Tue, 23 Dec 2008 17:47:49 -0600, VanguardLH <(email address - cut out)> wrote:
>
>>Steve Jain [MVP] wrote:
>>
>>>>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.
>>>
>>> You can. Once you select this and turn off the VM, the next time you
>>> do this, it will remember the last state.
>>
>>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).
>
> 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 wrote:
>
>> On Tue, 23 Dec 2008 17:47:49 -0600, VanguardLH <(email address - cut out)> wrote:
>>
>>>Steve Jain [MVP] wrote:
>>>
>>>>>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.
>>>>
>>>> You can. Once you select this and turn off the VM, the next time you
>>>> do this, it will remember the last state.
>>>
>>>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).
>>
>> 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.
>
> 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.
>
> Thanks.

> On Tue, 23 Dec 2008 18:05:23 -0600, VanguardLH <(email address - cut out)> wrote:
>
>>VanguardLH wrote:
>>
>>> Steve Jain [MVP] wrote:
>>>>
>>>> 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.
>>>
>>> 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.
>>
>>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?
>
> 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.

> On Tue, 23 Dec 2008 19:42:24 -0600, VanguardLH <(email address - cut out)> wrote:
>
>>Steve Jain [MVP] wrote:
>>
>>> On Tue, 23 Dec 2008 18:05:23 -0600, VanguardLH <(email address - cut out)> wrote:
>>>
>>>>VanguardLH wrote:
>>>>
>>>>> Steve Jain [MVP] wrote:
>>>>>>
>>>>>> 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.
>>>>>
>>>>> 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.
>>>>
>>>>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?
>>>
>>> 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.
>>
>>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).
>
> Definitely!
>
>>
>>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.
>
> You can also daisy chain diff disks. Create 1 parent, make a child of
> it, then you can write-protect that child and make it a parent for a
> "grand"child of the 1st disk.
> IIRC, you can go around 20-30 levels deep with diff-disks.

> On Tue, 23 Dec 2008 05:06:23 -0600, VanguardLH <(email address - cut out)> wrote:
>
>>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?
>
> 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 (Sweden)

>SaGS wrote:
>
>
>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.
>

>Steve Jain [MVP] wrote:
>
>>>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.
>>
>> You can. Once you select this and turn off the VM, the next time you
>> do this, it will remember the last state.
>
>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).

>select "discard" when I go to shut down the virtual machine and that would
>ONLY discard the changes since the LAST time I committed changes to the hard
>disk.
>
>"Bo Berglund" <(email address - cut out)> wrote in message
>news:(email address - cut out)...
>> On Tue, 23 Dec 2008 05:06:23 -0600, VanguardLH <(email address - cut out)> wrote:
>>
>>>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?
>>
>> 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.
>
>Really?! Wow, I sure misunderstood undo disk then (which is new to me
>because VMWare uses snapshots which is superior ...of course Workstation is
>expensive, unlike VPC which is free, so I don't mean to try and compare paid
>to free in terms of what you get). I thought that I could, at any time,
>select "discard" when I go to shut down the virtual machine and that would
>ONLY discard the changes since the LAST time I committed changes to the hard
>disk.
>
>>
>> --
>>
>> Bo Berglund (Sweden)
>