Splitting Virtualbox.xml configuration into settings and stateful data

Here you can provide suggestions on how to improve the product, website, etc.
cluelesscoder
Posts: 21
Joined: 27. Oct 2015, 19:41

Splitting Virtualbox.xml configuration into settings and stateful data

Post by cluelesscoder »

I like to put my configuration ("dotfiles") under version control. But I expect that my configuration doesn't change much - it reflects mostly customization preferences, not the data that the application works with.

It seems that Virtualbox.xml contains more than user settings and preferences - it seems to have machine entries and various other data, which means that it is constantly changing. I'll back it up (using borgbackup for incremental backups), but I'd rather version the configuration.

I did a search on the forum and tickets (https://www.virtualbox.org/search?q=Vir ... &ticket=on) but didn't find anything.

Has this been discussed before? If not, I may open a ticket.
socratis
Site Moderator
Posts: 27330
Joined: 22. Oct 2010, 11:03
Primary OS: Mac OS X other
VBox Version: PUEL
Guest OSses: Win(*>98), Linux*, OSX>10.5
Location: Greece

Re: Splitting Virtualbox.xml configuration into settings and stateful data

Post by socratis »

I'm not sure what you're asking for. Could you clarify which data should be stored somewhere else? What changes in the VirtualBox.xml should be moved? What changes should stay? And in the bottom line you're talking about a few KB, right?
Do NOT send me Personal Messages (PMs) for troubleshooting, they are simply deleted.
Do NOT reply with the "QUOTE" button, please use the "POST REPLY", at the bottom of the form.
If you obfuscate any information requested, I will obfuscate my response. These are virtual UUIDs, not real ones.
mpack
Site Moderator
Posts: 39156
Joined: 4. Sep 2008, 17:09
Primary OS: MS Windows 10
VBox Version: PUEL
Guest OSses: Mostly XP

Re: Splitting Virtualbox.xml configuration into settings and stateful data

Post by mpack »

cluelesscoder wrote: It seems that Virtualbox.xml contains more than user settings and preferences - it seems to have machine entries and various other data, which means that it is constantly changing.
VirtualBox.xml contains the settings for the front end. Primarily it contains the list of registered VMs, including for each one a path, name, and UUID. This must be accessible to the VBoxManage app and the VBoxSVC background task. All of this data is private, none of it is user editable. None of it even really needs to be backed up, since it can all be easily regenerated at a slight cost in convenience. Like Socratis I'm not seeing the virtue in splitting this already very small file.
scottgus1
Site Moderator
Posts: 20965
Joined: 30. Dec 2009, 20:14
Primary OS: MS Windows 10
VBox Version: PUEL
Guest OSses: Windows, Linux

Re: Splitting Virtualbox.xml configuration into settings and stateful data

Post by scottgus1 »

If you are sure that there are no Virtualbox guests, programs, or services running (you can test for this with a script if you know what to test for), you can copy the .Virtualbox folder to another dated & timed location (ie. a backup) and then you can restore from that location later if desired. Just be sure that Virtualbox is completely not running when backing up or restoring: use Process Explorer on Windows hosts or Mac/Linux equivalent to see what runs when the main Virtualbox window or a guest is started.

Might be best to do the whole .Virtualbox folder rather than just the XML. There's logs that go with the services and main Virtualbox window runs that should go also with Virtualbox.xml.
cluelesscoder
Posts: 21
Joined: 27. Oct 2015, 19:41

Re: Splitting Virtualbox.xml configuration into settings and stateful data

Post by cluelesscoder »

Primarily it contains the list of registered VMs, including for each one a path, name, and UUID. This must be accessible to the VBoxManage app and the VBoxSVC background task. All of this data is private, none of it is user editable. None of it even really needs to be backed up, since it can all be easily regenerated at a slight cost in convenience. Like Socratis I'm not seeing the virtue in splitting this already very small file.
It also contains some configuration bits, such as the Default Machine Folder.

Do you see why I would want that split out from the list of registered VMs? Configuration like this is much less mutable than the day-to-day changes of which VMs I'm working with. And if I'm working in a team environment where I want everyone to be on the same page, I can share that config.

In this case there doesn't seem to be too much configuration so I guess it's not a big deal but it's a good general approach.
mpack
Site Moderator
Posts: 39156
Joined: 4. Sep 2008, 17:09
Primary OS: MS Windows 10
VBox Version: PUEL
Guest OSses: Mostly XP

Re: Splitting Virtualbox.xml configuration into settings and stateful data

Post by mpack »

cluelesscoder wrote: It also contains some configuration bits, such as the Default Machine Folder.
Which does not affect any existing VM. It's just a stored preference affecting only the front end app. Exactly the same as the recent files list.

Frankly, it's clear that you do not understand the purpose of the fields in VirtualBox.xml, so your suggestions are bound to be weighted accordingly.
scottgus1
Site Moderator
Posts: 20965
Joined: 30. Dec 2009, 20:14
Primary OS: MS Windows 10
VBox Version: PUEL
Guest OSses: Windows, Linux

Re: Splitting Virtualbox.xml configuration into settings and stateful data

Post by scottgus1 »

Just had a thought pop in mind for where Cluelesscoder's idea may find a field:
cluelesscoder wrote:if I'm working in a team environment where I want everyone to be on the same page, I can share that config.
Sharing a full Virtualbox.xml would also share the list of guests, which may not be the same on all hosts. If C wants, for example, to set up a certain arrangement of Host-Onlys and NATnetworks he might be thinking that having these aspects in a different file than the guest list may help his project to share the network settings, or the default machine folder, or other non-guest-list settings.

Cluelesscoder, you will have a few things that will probably not allow this suggestion to go forward.

1. Virtualbox would need to be backwards-compatible between the old one-file and the proposed two- or multi-file system. Backwards compatibility is hard to achieve.

2. Oracle's development on free Virtualbox comes from developments on Oracle's pay-for virtualization system which is derived from Virtualbox. The license to begin getting developer support on Oracle's pay-for virtualization product starts at $1220 for the "Socket" version (whatever that means) or $6100 ($61 per license, 100 license minimum, for the multi-seat license). The developers have said they have their hands over-full handling Oracle's customers' development needs, so enhancements suggested by free users may not be be high on the list unless the enhancements coincide with rich paying customers' needs, or unless the developers see it on the Bugtracker and fall head-over-heels in love with it.

3. Simply swaping XMLs may not trigger the parts of the program that actually generate the changes the settings swap would call for. Using the main window or the command line may be the only way to cause the changes reliably.

4. You can use the command line now, in a batch file to make the changes you want, and distribute the batch file.
cluelesscoder
Posts: 21
Joined: 27. Oct 2015, 19:41

Re: Splitting Virtualbox.xml configuration into settings and stateful data

Post by cluelesscoder »

I think scottgus1 gets why I think this would be helpful. And great point about sharing a shell script!

mpack - as scottgus mentioned, there are several more options which make more sense to share in the team environment. Also, keyboard shortcuts get saved to the file if you add them. I imagine there are other configs that either are saved into a file or could be saved down the line. For example, maybe changing the default way that VMs are created to use something other than AC97 for the sound. ;)

The biggest barrier might be backwards compatibility, altho I could see code that checks if the new files exists and falls back to the old single file working OK. Honestly, it is more important for me to plant the seed than it is to see this implemented, especially since I can use a shell script and it looks like I'll be doing a lot of work thru Vagrant / Packer at this point, and those tools don't seem to mix config and data.

Splitting data and configuration is consistent with a trend in the *nix world driven by the XDG Base Directory standard (from 2003, see https://wiki.archlinux.org/index.php/XD ... ry_support) which recommends splitting data and configuration.
mpack
Site Moderator
Posts: 39156
Joined: 4. Sep 2008, 17:09
Primary OS: MS Windows 10
VBox Version: PUEL
Guest OSses: Mostly XP

Re: Splitting Virtualbox.xml configuration into settings and stateful data

Post by mpack »

cluelesscoder wrote: Splitting data and configuration is consistent with a trend in the *nix world
VirtualBox already splits data and configuration. The problem is that you want to quibble about which is which.
cluelesscoder
Posts: 21
Joined: 27. Oct 2015, 19:41

Re: Splitting Virtualbox.xml configuration into settings and stateful data

Post by cluelesscoder »

A list of registered guest machines and a list of recent files are not configuration. How could they be possibly considered configuration by any reasonable definition of the word?

Configuration controls how the application behaves. It's not the list of stuff you add, delete, and so on.
mpack
Site Moderator
Posts: 39156
Joined: 4. Sep 2008, 17:09
Primary OS: MS Windows 10
VBox Version: PUEL
Guest OSses: Mostly XP

Re: Splitting Virtualbox.xml configuration into settings and stateful data

Post by mpack »

cluelesscoder wrote: Configuration controls how the application behaves. It's not the list of stuff you add, delete, and so on.
I'm not aware of that definition, and I'm pretty sure I don't want to be.

In fact when it comes right down to it, everything on the disk is data. However it's true that we can usefully distinguish between code and other data. I'll accept that we can further categorize data into user work product (this needs to be backed up), and application generated files (which usually don't, because the app can always generate them again). VirtualBox.xml is the latter.

The content of the data file is irrelevant.
erdeslawe
Volunteer
Posts: 241
Joined: 8. Jul 2015, 10:23

Re: Splitting Virtualbox.xml configuration into settings and stateful data

Post by erdeslawe »

In Computing Terms, Configuration Is defined as: "The arrangement or set-up of the hardware and software that make up a computer system." Ergo, the existence a number of virtual operating systems existing on the same physical system is clearly a part of it's software configuration; and also a part of the specific configuration of a working VirtualBox installation.
socratis
Site Moderator
Posts: 27330
Joined: 22. Oct 2010, 11:03
Primary OS: Mac OS X other
VBox Version: PUEL
Guest OSses: Win(*>98), Linux*, OSX>10.5
Location: Greece

Re: Splitting Virtualbox.xml configuration into settings and stateful data

Post by socratis »

The whole discussion would be moot if the OP didn't want to share their "configuration" with other users. That's where the OP's logic breaks down. They're looking for a definition that will suit their specific needs. They want to distort the definition to fit their needs. Nobody has to "translate" their wants into reality...
Do NOT send me Personal Messages (PMs) for troubleshooting, they are simply deleted.
Do NOT reply with the "QUOTE" button, please use the "POST REPLY", at the bottom of the form.
If you obfuscate any information requested, I will obfuscate my response. These are virtual UUIDs, not real ones.
cluelesscoder
Posts: 21
Joined: 27. Oct 2015, 19:41

Re: Splitting Virtualbox.xml configuration into settings and stateful data

Post by cluelesscoder »

In Computing Terms, Configuration Is defined as: "The arrangement or set-up of the hardware and software that make up a computer system." Ergo, the existence a number of virtual operating systems existing on the same physical system is clearly a part of it's software configuration; and also a part of the specific configuration of a working VirtualBox installation.
Where does that come from?

OK, so I'm talking about configuration in the sense that https://en.wikipedia.org/wiki/Configuration_file discusses:

"In computing, configuration files, or config files configure the parameters and initial settings for some computer programs. They are used for user applications, server processes and operating system settings."

In software engineering, we've often found this distinction helpful - it is ubiquitous in both Windows and Unix software.

I personally code on an enterprise software system and we clearly demarcate the system configuration on multiple levels (enterprise account, subenterprise team, user) so that these can be backed up, shared separately, etc. We try not to mix the concerns of data (generic) and settings. It would be a rather poor practice if someone tried to import a bunch of the business data but could not because they had a different timezone setting.
socratis
Site Moderator
Posts: 27330
Joined: 22. Oct 2010, 11:03
Primary OS: Mac OS X other
VBox Version: PUEL
Guest OSses: Win(*>98), Linux*, OSX>10.5
Location: Greece

Re: Splitting Virtualbox.xml configuration into settings and stateful data

Post by socratis »

cluelesscoder wrote:I personally code on an enterprise software system
Maybe that's where the misunderstanding comes in. VirtualBox's design was not meant for it to be shared, not even among different users on the same machine. It's a per-user configuration, strictly. Even the configuration files are saved not world read-write, but user-only read-write, world/group no-access. On purpose, for security reasons.

I wanted to share VMs among different users on my Mac (mainly the Doudou Linux with my then younger daughter). A pain in the kister. Had to 'sudo' every time that we wanted to switch who had access to the VM (of course not concurrently, that's an even bigger no-no).

What you're thinking of doing is beyond the design goals of VirtualBox. That means that you have to find some means to accommodate your specific needs. 'VBoxManage' in the command-line plus some scripts are your best friends at this point. I wouldn't expect the whole VirtualBox philosophy to change over a lone wolf's needs. And please don't take this personally.
Do NOT send me Personal Messages (PMs) for troubleshooting, they are simply deleted.
Do NOT reply with the "QUOTE" button, please use the "POST REPLY", at the bottom of the form.
If you obfuscate any information requested, I will obfuscate my response. These are virtual UUIDs, not real ones.
Post Reply