Firewall VM Changes not persisting

[dkindlund]

I've been trying to use the Firewall VM mentioned in the user guide. I initially ran into trouble with the VM automatically running an svn update http://www.honeyclient.org/trac/ticket/200 though that should have been solved by deleting the line from the .sh file. Unfortunately, this change did not persist.

Attempting to modify the state of the VM to persistant lead to the VM breaking and failing to restart citing: {{{ Cannot open the disk '/vm/firewall-3/honeywall.vmdk' or one of the snapshot disks it depends on. Reason: Failed to lock the file. }}}

Attempting to restore the state of the VM to normal (non-independant) operation still results in the same error.

Please help!

[dkindlund]

Author: kindlund Hrm, I see what you mean. Originally, the firewall VM was configured to run in "undoable" mode. Meaning, if any changes were made to the VM, upon power off, those changes would be automatically discarded. The best way to resolve this is:

1. Start from a fresh firewall VM
2. Edit the .cfg file to change all references of "undoable" to "persistent"
3. Register the VM
4. Power on the VM and disconnect the network
5. Edit the VM details to disable auto update
6. Shutdown and power off VM
7. Power on VM and verify the changes stuck

-- Darien

[dkindlund]

Author: aaron.blum@gmail.com Are we talking about the honeywall.vmx file?

[dkindlund]

Author: kindlund Correct.

[dkindlund]

Author: aaron.blum@gmail.com I don't see any references to "undoable" though there is a line: {{{ scsi0:0.mode = "nonpersistent" }}}

There are also a lines: {{{ scsi0:0.redo = "/tmp/honeywall.vmdk.REDO_hzTUea"

redoLogDir = "/tmp" }}}

Should I switch the mode line and should I do anything with the redo line?

[dkindlund]

Author: kindlund Just change this line: {{{ scsi0:0.mode = "nonpersistent" }}}

To read: {{{ scsi0:0.mode = "persistent" }}}

You can ignore everything else.

-- Darien

[dkindlund]

Author: aaron.blum@gmail.com That results in the same error. However, loading the VM with the network kicked out, making the change and then hitting the snapshot button seems to have given me a temporary fix. Not sure if that's the best way but it seems to be working.

[dkindlund]

Author: aaron.blum@gmail.com Disregard the temporary fix listed above, I inadvertently still had the network kicked out when I brought the snapshot fix up. When I brought it up this morning it did the svn update from the site and broke the daemon :(

[dkindlund]

Author: kindlund So, to clarify, even with the Firewall VM's network disabled, the svn update process still caused the VM to not function properly? Have you tried just issuing a CTRL-C when you see the svn update start?

-- Darien

[dkindlund]

Author: Aaron aaron.blum@gmail.com Sorry, let me clarify:

With the VM network adapter disabled on load the firewall VM [v3] comes up just fine. Then I have to manually go into vmware and "connect" the adapters.

If however, I allow the adapters to be connected on boot, it goes out and updates. I haven't tried Ctr-C yet since it generally drops pretty quickly into the update and I didn't want to kill it mid svn update.

Right now, I have my VMware Server configured so that the VM has both network adapters disconnected on boot and then I manually turn them on. Is there a guide or design doc detailing the configuration of the firewall VM that I can use to create a compatible VM of my own?

[dkindlund]

Author: kindlund Based on what we discussed, this should be a one-time problem. Meaning, with the VM off, mark the firewall VM as persistent, disconnect network connectivity, boot the firewall VM, login, disable svn update in the startup script, shutdown the VM, reconnect network connectivity, and then start it up. From that point on, the firewall VM should never perform svn updates again -- ever. If you're still having problems getting this to work, I can try to re-roll a v4 of the firewall VM without svn update functionality, but that will take some time.

-- Darien

[dkindlund]

Author: Aaron aaron.blum@gmail.com Marking the firewall as persistent both through the GUI and via the config file results in a broken VM. When done via the vmware utility, I get an error referencing some non-existent snapshot file (can get you the exact name tonight if you need it).

Modification of the config fie results in the following error: "Cannot check for the existence of an old redo log for disk 'honeywall-000005.vmdk'. Failed to configure disk scsi0:0. The virtual machine cannot be powered on with an unconfigured disk. "

It is also noteworthy the line {{{ scsi0:0.redo = "/tmp/honeywall.vmdk.REDO_hzTUea" }}} mentioned above becomes {{{ scsi0:0.redo = "" }}} after I attempt to load the VM after modification of the honeywall.vmx config file.

[dkindlund]

Author: kindlund When you're modifying the VM's .cfg/.vmx configuration file, you should always do this using a standalone editor -- not using any type of GUI. When you use the original firewall VM from the .tar.gz archive, I believe there are no .REDO files included.

Are you saying that: (1) you've extracted a fresh copy of firewall-3.tar.gz into an empty directory, (2) edited the corresponding .vmx/.cfg file, and (3) encounter this error message when you subsequently register/power on this VM? If so, then yes, it sounds like I'll have to re-roll a v4 of the firewall to resolve this issue.

-- Darien

[dkindlund]

Author: Aaron aaron.blum@gmail.com

Are you saying that: (1) you've extracted a fresh copy of firewall-3.tar.gz into an empty directory, yes (2) edited the corresponding .vmx/.cfg file, and yes (3) encounter this error message when you subsequently register/power on this VM? yes

Also, the gui that I mentioned is the vmware interface that I use for powering on and interacting with the virtual machines. I went to "Edit virtual machine settings"->"Advanced" and change the hard disk mode to independent and ensured the radio button for "persistent" was selected. This test was done with a separate untarred copy of the vm from the one where I edited the config file directly (using vi).

The corresponding error for the GUI edit is: {{{ Cannot open the disk '/vm/firewall-3/honeywall.vmdk' or one of the snapshot disks it depends on. Reason: Failed to lock the file. }}}

[dkindlund]

Author: kindlund I think I know what the problem is. Retry the same operations, but, after extracting the fresh VM, DELETE the file "firewall-3/honeywall.vmdk.READLOCK" then proceed to register the VM and change to persistent. Let me know if that works for you.

-- Darien

[dkindlund]

Author: Aaron aaron.blum@gmail.com Still not working but different error.

Step by step this is what I did: I unregistered all my virtual machines so the server was clean, started with a freshly untarred firewall-3. {{{ root@ubuntu:/opt# tar xvf firewall-3.tar.gz

root@ubuntu:/opt# mv firewall-3 /vm root@ubuntu:/opt# cd /vm root@ubuntu:/vm# chown -R hcuser:hcuser firewall-3 root@ubuntu:/vm# cd firewall-3/ root@ubuntu:/vm/firewall-3# rm honeywall.vmdk.READLOCK root@ubuntu:/vm/firewall-3# vmware-cmd -s register /vm/firewall-3/honeywall.vmx register(/vm/firewall-3/honeywall.vmx) = 1 }}} If I change the persistence state from the vmware application I get the following error: "''Unable to change virtual machine power state: The Process exited with an error: End of error message''" The hard-disk also disappears from the VM configuration. I restored it by adding it as an existing disk image to the Firewall VM [v3]; attempted to boot and got exactly the same behavior, the above error and the vm disk disappeared. I started from scratch again this time only modifying the configuration using ''vi''. That resulted in this familiar error on power up: "''Cannot open the disk '/vm/firewall-3/honeywall.vmdk' or one of the snapshot disks it depends on. Reason: insufficient permission to access file.''"

[dkindlund]

Author: Aaron aaron.blum@gmail.com I think that the permission issue might be something amiss with my system, I encountered the same issue when attempting to run the honeyclient startManager.pl script but the script ran fine when I invoked it as root. What username and permissions should the /vm directory and subfolders carry?

[dkindlund]

Author: kindlund Okay, try doing a 'chmod -R 770' on all the data. If you're not running your shell as root, then you need to 'chown -R' the data to reflect the user/group you're running the shell under. Keep in mind that if you're changing owners, YOU WILL NEED TO UNREGISTER the VM from VMware Server first; then chown; and then re-register the VM. VMware Server has no automatic logic to detect when owner's change; I believe it does with permissions, but not ownership.

Let me know if this works when performing the same steps using vi.

-- Darien

[dkindlund]

Author: Aaron aaron.blum@gmail.com Success!

Started with a newly unzip copy of the firewall VM again. Then: {{{ $chown -R hcuser:hcuser /vm $chmod -R 770 /vm $vi /vm/firewall-3/honeywall.vmx }}}

Changed the line: {{{ scsi0:0.mode = "persistent" }}} to {{{ scsi0:0.mode = "nonpersistent" }}}

1. Booted the firewall VM with network disabled.
2. Modified /hc/startFWListener.sh to disable svn update.
3. Shutdown the VM.
4. Re-enabled the network adapters on the firewall-3 VM.
5. Restarted the VM and confirmed that the change persisted and that the Manager daemon was still running.

Thanks for all your help!

[dkindlund]

Author: kindlund Great! Glad to hear that it worked.

-- Darien