VirtualBox

Changes between Initial Version and Version 7 of Ticket #3351


Ignore:
Timestamp:
05/04/09 14:37:07 (5 years ago)
Author:
frank
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #3351 – Description

    initial v7  
    1 Currently the VBox metadata models are denormalised in that data elements are duplicated between the central `VirtualBox.xml` registry and the various machine.xml files.  The VBox application does not enforce proper transactional integrity between these various definition files and so various program errors can cause them to get out of sync.  A result of this is that VBox will then refuse to load the VM and the users are unable to recover the contents of any snapshotted HDs with understanding the XML schemas and manually patching up the XML files — not something that the average use is capable of doing.  Hence certain classes of VBox error can result in major data loss for most users.  There is sufficient volume of posts on the forum related to this issue to support the conclusion that this is a real problem. 
     1Currently the VBox metadata models are denormalised in that data elements are duplicated between the central ''!VirtualBox.xml'' registry and the various machine.xml files.  The VBox application does not enforce proper transactional integrity between these various definition files and so various program errors can cause them to get out of sync.  A result of this is that VBox will then refuse to load the VM and the users are unable to recover the contents of any snapshotted HDs with understanding the XML schemas and manually patching up the XML files — not something that the average use is capable of doing.  Hence certain classes of VBox error can result in major data loss for most users.  There is sufficient volume of posts on the forum related to this issue to support the conclusion that this is a real problem. 
    22 
    33As far as I can see there are three possible approaches to remove this product vulnerability: 
    4  
    5 * '''Renormalise the data models'''.  For example the `<MediaRegistry><HardDisks>` tree would only contain HDs that are not allocated to VMs.  The complete set of `<HardDisks>` could be obtained by enumerating this tree plus the `<HardDisks>` in each attached machine.  (This node would replace the existing `<HardDiskAttachments>` node).  Such an approach would also mean that a VM is now a self-contained entity that can be exported or imported (a frequent user request).  Yes this would require addition integrity checks to walk the VMs XML files when adding or removing HDs, but this is hardly a frequent occurrence.  This is my recommended option. 
    6  
    7 * '''Provide a repair too'''.  This would walk the various XML files, identify inconsistencies and have a set of rules for when to recommend recovery and when to ask the user for a choice. 
    8  
    9 * '''Move the meta data to a proper DB'''.  The obvious one to use here is SQLlite: simple, free, and able to handle the transactional issues.  Under this scenario the Machine schema would only be used for importing and exporting machines. 
    10  
     4 * '''Renormalise the data models'''.  For example the ''<!MediaRegistry><!HardDisks>'' tree would only contain HDs that are not allocated to VMs.  The complete set of ''<!HardDisks>'' could be obtained by enumerating this tree plus the ''<!HardDisks>'' in each attached machine.  (This node would replace the existing ''<!HardDiskAttachments>'' node).  Such an approach would also mean that a VM is now a self-contained entity that can be exported or imported (a frequent user request).  Yes this would require addition integrity checks to walk the VMs XML files when adding or removing HDs, but this is hardly a frequent occurrence.  This is my recommended option. 
     5 * '''Provide a repair too'''.  This would walk the various XML files, identify inconsistencies and have a set of rules for when to recommend recovery and when to ask the user for a choice. 
     6 * '''Move the meta data to a proper DB'''.  The obvious one to use here is SQLlite: simple, free, and able to handle the transactional issues.  Under this scenario the Machine schema would only be used for importing and exporting machines. 
    117This metadata is critical to the protecting the user content maintained within the various VMs, yet there are no transactional, journalling or recovery mechanisms provided to ensure the integrity of this metadata.  This is unacceptable in product of VBox's maturity. 

www.oracle.com
ContactPrivacy policyTerms of Use