virtualbox.org

The PDF documentation makes it sound easy. A search here on "immutable" finds multiple suggestions to just do it, with no indication how. Here are two methods that do not work.

1. Export the (normal) VM I want to clone as immutable. Import it with a new name. Start it, to make sure it still works. Shut it down. In a Command window, runthe result isOK, so it wants me to disconnect it.
2. Do what that message appears to suggest.

• VirtualBox | File | Virtual Media Manager | Highlight the HD | Release | Remove.
  In a Command window, execute the VBoxManage modifyhd command. Completes normally.
  Return to VirtualBox and the selected VM.
  Details | Storage | IDE Controller | (2nd) Add Hard Drive
  Click on the HD Icon. It gives me the first HD. [see Note below]
  Add a second HD (the one I want). Swap IDE assignments.
  Delete the first HD.

The result is not immutable, as I have verified by changing bookmarks in Firefox, shutting the VM down and restarting it. The bookmarks remain changed.

Note: My Hard Disk folder contains 15 files, so it was fortunate that the one I had tried to set immutable was the second one, by coincidence of the UUID generator. The fact that the "Add" function does not allow one to choose the file, but simply adds them to the VM in numerical order, is potentially very inconvenient.

In conclusion, I am certain that the process of creating an immutable hard drive is not this difficult, but I have not been able to discern it from either the PDF documentation or from the options presented by the Virtual Media Manager and the VBoxManage command. I have provided the above details in hopes that when the explanation is added to this thread, visitors may find the answer through a search that leads to this thread.

Please provide the details of a simple process for creating an immutable hard drive.

Thanks!

I notice that the user manual seems to be missing a detailed syntax statement for the "VBoxManage modifyhd" command, which all the other commands seem to have. However the following works fine for me :
Given the error message you saw I made sure that the disk <filename> was registered in virtual media manager, but not yet mounted in any VM. Obviously you can't set a disk to immutable if it isn't registered, since the immutable and passthrough types are just registry flags, not permanent attributes of the disk itself.

Personally, I think the easiest way to make an immutable drive is to edit VirtualBox.xml with Notepad++, and change the disk type in the media registry section from type="Normal" to type="Immutable".

Thanks very much for the reply, mpack.

mpack wrote:Obviously you can't set a disk to immutable if it isn't registered, since the immutable and passthrough types are just registry flags, not permanent attributes of the disk itself.

What is obvious to the guru may not be obvious to the basic user! I think I have followed your directions, but the result is still not immutable. This may well be because my unregister-reregister has produced a nonstandard configuration.

I give each VM a separate folder on an external hard disk. Thus
F:\Machines\xyzzy\ contains xyzzy.xml and the folder Logs.
xyzzy.xml contains <AttachedDevice ...> <Image uuid="{b4f7344a...}"/>
Back on the system disk, \D&S\..\VirtualBox.xml contains
<MachineRegistry> <MachineEntry uuid="{6ed00325...}" src="F:\Machines\xyzzy\xyzzy.xml"/>
and
<HardDisk uuid="{b4f7344a..}" location="F:\HardDisks\{6c472def..}.vmdk" format="VMDK" type="Immutable"/>
where I have changed "Normal" to "Immutable" as you suggested.

Now, when I move an icon on the desktop and change Firefox bookmarks, closing and restarting VM xyzzy finds the changes remain.

There is no "Normal" flag inside F:\Machines\xyzzy\xyzzy.xml and the xyzzy.ovf of the machine I imported has no "Normal type" though it has some ResourceTypes.

My inclination is to delete the present trial VM, reimport the OVF and try your suggestion before the first run of the new VM. Is there anything I should identify in the present VM to clarify what has (not) happened before I delete it?

It's a little hard to follow what exactly you are doing, i.e. why you are discussing import and export. The media registry is stored in the VirtualBox.xml file and includes everything important that VBox needs to know about each disk image that isn't (or may not) be stored in the image itself. Information about a disk image is not stored in the VM xmls, the VM xml instead has information about the VM, inluding media registry references (by UUID) to all mounted disk images.

I would also not assume that import/export preserves "volatile" media registry flags. The OVF format is a standard defined by VMware, and I don't know how flexible it is or how well it maps to VirtualBox functionality.

(A) I am a dummy. (B) I have an XP multimedia VM, configured the way I like it. I want to create a clone of it by the simplest method available and make the clone immutable. (C) Since I have successfully exported and re-imported VMs before, I chose that as the first step. I don't trust myself trying to "clone" an HD and set up other parts of the VM construct correctly.

I have now tried 3 methods to make a VM "immutable", none of which have worked. I have searched (1) the current documentation, (2) this forum and (3) the internet in general, and not found a tutorial for the process. That reinforces my suspicion that I don't understand enough of the details.

That is why I am attempting to document my problems in enough detail that someone else who finds this thread will not have to make these mistakes.

docduke wrote:I want to create a clone of it by the simplest method available and make the clone immutable.

I've never actually used import/export since I prefer to clone the VM manually, that way I know what I'm getting. However, I would have thought that the simplest way to do what you want using something similar to what you've tried is, export, followed by import - which hopefully creates an independant copy of the disk image - then before running the VM you edit VirtualBox.xml using Notepad++ (making sure that no part of VBox is running at the time) and change the type of the clones disk to immutable. If you run the VM and check in media manager it should report "Immutable" if you succeeded. The exact effect or limitations of using an immutable drive is again something I've never had a need to find out so can't comment on.

.. edit VirtualBox.xml using Notepad++ (making sure that no part of VBox is running at the time) ...

You have just put your finger on my latest problem. I did the Notepad++ edit with the VirtualBox program running (though no VMs). I closed and restarted it, and now it tells me "xyzzy Inaccessible":So it is definitely time to delete this VM and start over. I am getting low on host disk space, so I first need to do some cleanup. I will also spend some time with Grep to see if I can locate the UUID and IMachine strings, to make sure I have cleaned up completely.

Never underestimate the amount of trouble a novice can get into!

Hopefully, I will be able to retry this by tomorrow with a clean import and a VirtualBox.xml edit with nothing involving VirtualBox running at the time! Thanks again, mpack, for all the help!

Tried it: Delete the xyzzy VM, delete the corresponding HD. Reimport it. Shut down VirtualBox. Edit VirtualBox.xml and change type="Normal" to type="Immutable".

Result: Same as before. That is: xyzzy is inaccessible. "Immutable hard disk ... cannot be directly attached to the virtual machine xyzzy.

My conclusions: 1. Directly editing VirtualBox.xml does not work. It fails because VirtualBox refuses to accept the change. 2. "VboxManage <filename> modifyhd --type immutable" does not work. It fails because the file "is attached to 1 virtual machines". 3. The PDF documentation of VirtualBox, pages 82 and 130 say that a "hard drive" can be rendered immutable, but they give no indication how that can be done.

So, mpack, back to your hints above. Delete the xyzzy VM. Run the VBoxManage command. Now it works. Reconstruct the VM: New | xyzzy | Memory, same as before | Hard Disk, Use existing hard disk, select it from the list. (It's easy to find, because it's the only one that is "Immutable" | Finish. That was easy!
Now, does it run? Yes, but it's installing updates. Now change some things. Immutable?
Yes! The changes went away, and it is reinstalling the updates!

In retrospect, the direct editing of VirtualBox.xml might have worked if I had deleted the xyzzy VM in the left window of Sun VirtualBox first, done the edit, then recreated the VM. Some other time ...

Thanks again, mpack, for the essential information. The key lesson is that it is necessary to not just shut off VirtualBox, but actually delete the VM entry before changing a disk from "normal" to "immutable." Lesson learned!

Well done, I'm glad you got it working.

Postscript: The export-import step appears to be necessary. The problem is that Sun VirtualBox keeps a snapshot of the last run, even though I may not have taken any formal snapshots. Therefore, it is not enough to change the "Hard Drive" file to immutable.
The process I have verified to work as one would expect is:
1. Get the prototype VM configured exactly as desired for the immutable VM.
2. Export it. This merges the base HD and the snapshot(s) into a single VMDK file.
3. Import the result. Do not start it!
4. Delete the new entry in the list of VMs.
5. Now run the VBoxManage modifyhd command to make the HD immutable.
6. Create a new VM and configure it to use the immutable HD.
That does it, and the Sun VirtualBox window can be left up throughout the process. I hope this helps others to avoid the frustrations I have gone through getting this to work! Now I have a VM I can use to browse those websites that I'm curious about, but suspect may be infested with malware.

I would appreciate having a VM guru explain what "immutable" means for a VM. The reason I am asking is this: I have just discovered that my "immutable" VM has a 1.3 GB snapshot file containing the URLs of websites I have browsed using this "immutable" virtual machine. If it is really immutable, why does it have a history of what I have been doing in it?

It appears that the Virtual Media Manager can "Release" (and probably then Remove) the snapshot file. Will doing that regularly get me back to a truly "immutable" VM, or will deleting the snapshot render the VM unusable?

I am using VB Version3.1.8 r61349. It is certainly possible that this has been changed since then.

Immutable - a label applied to a drive rather than a VM - means that the base VDI contents are frozen and writes go to a changes file instead. Next time you run the VM the change list is reset to zero, effectively reverting the contents of the virtual disk to that of the base image. A difference image is the same, except the reset step doesn't happen. The changes file looks like a snapshot because it uses the same difference image technology that snapshots use.

All of this is in the user manual, chapter 5. The only relevant feature that has changed since v3.1.8 is that v4.x now stores the media registry for a new VM in its settings xml (which now has a .vbox extension), rather than in VirtualBox.xml.

I must be missing something.

Now I have a VM I can use to browse those websites that I'm curious about, but suspect may be infested with malware.

I use a batch file to copy a 'virgin' *.vbhdd file over the current one. Run the batch file after closing down the VM. Next time I run up VBox, I'm starting clean.

I am the one who is missing something. "Attention to detail" would be a likely candidate. I thought I understood what "immutable" meant, and after further study of the details, my guess is not very far from what VirtualBox does.
1. I just started the immutable VM again, and the 1.3 GB "current state" file disappeared, to be replaced by a small file that expanded after I used the browser and closed the VM. It didn't occur to me that the 1.3 GB "current state" snapshot could be from a single browsing session. It appears that browsing videos leaves voluminous history! It also makes sense, from a developer's point of view, to leave that file around after the immutable VM is closed. If something unexpected occurred during the session, the record remains so that it can be analyzed (by someone more knowledgeable than I, who knows the internal structure of the snapshot).
2. The manual is indeed very clear about how immutable images are treated, and it's basically the same in the 3.1.8 manual and the 4.0.4 manual, however, the Version 4 manual also mentions a new kind of image mode: the multiattach mode. This convinces me to upgrade my VBox software. I spend considerable time setting an OS VM just the way I want it, then create a number of variants. This looks like a useful tool for saving hard disk space on the host computer, but beyond the scope of this thread.
3. mpack, several posts back, you said Personally, I think the easiest way to make an immutable drive is to edit VirtualBox.xml with Notepad++, and change the disk type in the media registry section from type="Normal" to type="Immutable". Please confirm that there are no changes needed to the VM file itself in changing it from "Normal" to "Immutable." Now that I understand what you meant, that certainly seems like the simplest method!
4. timtimtim: I searched both manuals for "vbhdd" and got no hits. I am guessing you are using that as a generic term for the "Disk image ?les (VDI, VMDK, VHD, HDD)" of Section 5.2 of the manual. Now that I have applied Notepad++ to VMDK files, I have noticed the ASCII description near the front of the VM image, including the Extent description and Disk Data Base. If the documentation of the variables in those blocks are in the Manual, I haven't been able to find them. "VBoxManage showvminfo" appears to extract some of that information, but I haven't found a discussion of the values for those variables. Do you know of another document that describes them?

Every time I bring a problem to this Board, I find very knowledgeable and helpful responses. Thanks, folks!

docduke wrote:Please confirm that there are no changes needed to the VM file itself in changing it from "Normal" to "Immutable." Now that I understand what you meant, that certainly seems like the simplest method!

Again, I assume you mean "disk image" rather than VM (one VM may have several disks attached). I can confirm that no change needs to be made to the drive image itself if you want to make it immutable. "Immutable" is simply a post-it note telling VirtualBox how you want the drive image to be used, rather than being a feature of the drive image itself.