Multiattach disks break snapshotting

[Stephen Thomas]

Steps to reproduce:

1. Move the .VirtualBox and "VirtualBox VMs" folders aside to force VirtualBox to start with fresh ones.
2. Launch the VirtualBox GUI.
3. Click New to create a new VM.
4. At "Welcome to the New Virtual Machine Wizard!", click Next.
5. At "VM Name and OS Type", type master into the Name box and click Next.
6. At "Memory", click Next.
7. At "Virtual Hard Disk", click Next.
8. At "Welcome to the Create New Virtual Disk Wizard!", click Next.
9. At "Hard Disk Storage Type", click Next.
10. At "Virtual Disk Location and Size", click Next.
11. At "Summary", click Finish to dismiss the Virtual Disk Wizard.
12. At "Summary", click Finish to dismiss the Virtual Machine Wizard.

The GUI should now be showing you a new Windows XP VM called "master".

13. Choose File->Virtual Media Manager.
14. Click "master.vdi", then click Release, click Release to confirm, then click OK to dismiss the Virtual Media Manager.
15. In a Terminal window, type

    vboxmanage modifyhd VirtualBox\ VMs/master/master.vdi --type multiattach
    

16. Back in the GUI, click New.
17. At "Welcome to the New Virtual Machine Wizard!", click Next.
18. At "VM Name and OS Type", type slave into the Name box and click Next.
19. At "Memory", click Next.
20. At "Virtual Hard Disk", click "Use existing hard disk", then click Next.
21. At "Summary", verify that the Boot Hard Disk is "master.vdi (Multi-attach, 10.00 GB)" and click Finish.

The GUI should now be showing you two Windows XP VMs, "master" and "slave".

22. Close the GUI, wait 15 seconds and open it again.
23. Click "slave", then click Snapshots.
24. Click the camera button to take a snapshot.
25. At "Take Snapshot of Virtual Machine", click OK.
26. Close the GUI, wait 15 seconds and open it again.

This procedure doesn't involve running a VM, so no log files are generated.

Expected result:

"Slave" should remain accessible and should have one snapshot titled "Snapshot 1".

Actual result:

GUI shows "slave" as "Inaccessible".

[Stephen Thomas]

Frank, you clearly use Trac more competently than I can. I think I've created this ticket with the wrong component - VMM seems to mean something other than Virtual Media Manager. Could you fix? Ta ever so.

[Stephen Thomas]

I've found a simpler process for getting the same effect. Looks like the multiattach VDI type is not specifically to blame; the problem also occurs when attaching a new VM to an existing normal VDI that already has a differencing disk.

Steps to reproduce

1. Move the .VirtualBox and "VirtualBox VMs" folders aside to force VirtualBox to start afresh.
2. Launch the VirtualBox GUI.
3. Click New to create a new VM.
4. At "Welcome to the New Virtual Machine Wizard!", click Next.
5. At "VM Name and OS Type", type master into the Name box and click Next.
6. At "Memory", click Next.
7. At "Virtual Hard Disk", click Next.
8. At "Welcome to the Create New Virtual Disk Wizard!", click Next.
9. At "Hard Disk Storage Type", click Next.
10. At "Virtual Disk Location and Size", click Next.
11. At "Summary", click Finish to dismiss the Virtual Disk Wizard.
12. At "Summary", click Finish to dismiss the Virtual Machine Wizard.
    
    We now have a new Windows XP VM called "master".
    
    
13. Click "master", then click Snapshots.
14. Click the camera button to take a snapshot.
15. At "Take Snapshot of Virtual Machine", click OK.
    
    Now we add a second VM:
    
    
16. Click New to create a new VM.
17. At "Welcome to the New Virtual Machine Wizard!", click Next.
18. At "VM Name and OS Type", type slave into the Name box and click Next.
19. At "Memory", click Next.
20. At "Virtual Hard Disk", click "Use existing hard disk", then click Next.
21. At "Summary", verify that the Boot Hard Disk is "master.vdi (Normal, 10.00 GB)" and click Finish.
    
    We want the second VM's writes to go in its own differencing disk, so make a snapshot:
    
    
22. Click "slave".
23. Click the camera button to take a snapshot.
24. At "Take Snapshot of Virtual Machine", click OK.
25. Close the GUI, wait 15 seconds and open it again.

Expected result:

"Slave" should remain accessible and should have one snapshot titled "Snapshot 1".

Actual result:

GUI shows "slave" as "Inaccessible".

[Stephen Thomas]

I'm starting to get the sinking feeling that this issue (and possibly several other recent reports of assorted snapshot breakage) are the result of a flaw in the design of the now-decentralized media registry rather than a simple coding fault.

For VM "Slave" to attach safely to any disk already in use by VM "Master", a differencing disk must be created for Slave's exclusive use. The natural place to put that is inside Slave's own subfolder of "VirtualBox VMs", and the natural place to keep track of Slave's attachment to that disk and any subsequent child disks is inside Slave.vbox.

However, this is not what's happening. Instead, the initial differencing disk created inside "VirtualBox VMs/Slave/Snapshots" is listed inside Master.vbox, as a child of one of Master's existing disks. I've attached vbox-debug-session.txt to illustrate this.

Keeping a media registry branch for Slave's disks inside Slave.vbox would require a change to the way that parent/child disk relationships are currently represented in XML.

At present these are captured implicitly, by nesting the <HardDisk> tags for a given disk's children inside the parent <HardDisk> tag. This is tidy and natural for a centralized registry, but not so good for a distributed one: representing a subtree inside a separate file requires some explicit link to the subtree's parent.

It seems to me that an outer <HardDisk> tag containing only a uuid attribute could do this quite neatly. But this is a New Thing, and would probably need more change and review than is appropriate for a simple maintenance release :(

[Stephen Thomas]

Shell script to re-centralize hard disk entries in VirtualBox 4 media registry

[Stephen Thomas]

Following up suspicions re. media registry decentralization has produced what seems to be a workaround. I've attached a script that moves hard disk registration entries back into the central .VirtualBox.xml file; if VirtualBox is shut down and this script run at any time between steps 12 and 22, the reported breakage does not occur.

[aeichner]

Please reopen if still relevant with a recent VirtualBox release.