I'm running out of space on my machine, due to multiple VMs. I figured I could free some space by deleting the root (and only) checkpoint of each VM. Is this safe? I figure that since it's a checkpoint, it should be safe to delete, but the warning says I'm "Deleting the VM" which is worrisome.
Related
Thank you for taking the time to read this. I am trying to complete a Lab for one of my classes and I am having an issues creating a new Metasploitable VM. I introduced an error when editing a file in the last one and had to delete it.
I am using a VMDK, obtained from SourceForge. The first machine installed with no issues. When trying to create a second machine I continually get "Can't overwrite medium..." comment when finishing the set-up.
So far I have tried:
Checking the destination folder for any existing files and folders (hidden too).
Redownloading Metasploitable
Assigning a new name to the VM, using different specs, etc.
Restarting my PC.
What I don't understand is that the error is stating, if I am not mistaken, that it is trying to overwrite the VMDK in my downloads file... when I am trying to save it in c:\Users\natsu\VirtualBox VMs. I have triple checked all fields before running the installer. I do not understand why this is happening, considering the first Metasploitable machine I had installed with absolutely no issues.
]
Due to increasing space consumption of WSL I was forced to move my WSL distros to another disk.
Ubuntu
docker-desktop
docker-desktop-data
I used these commands.
wsl --shutdown
wsl --export (on all three of those distros)
wsl --import (already on another disk)
Now my environment is running fine but the ext4.vhdx in AppData\Local\Docker\wsl\data is still present and I can't remove it due to it still being used.
When I look at process hadnles
Its still being used by system which is not telling much.
If I run WSL --shutdown all virtual disks present on disk E: lose their handles and the one on disk C: is still being used.
Would you know how to find out what part of WSL or if it even is WSL is using?
Since shutting down WSL does not remove that handle it might be used by something else.
Its not docker-for-desktop that one uses different disk.
Thanks for your suggestions.
Docker Desktop for Windows, which uses WSL2, stores all image and container files in a separate virtual volume (vhdx). This virtual hard disk file can automatically grow when it needs more space (to a certain limit). Unfortunately, if you reclaim some space, i.e. by removing unused images, vhdx doesn't shrink automatically. Luckily, you can reduce its size manually by calling this command in PowerShell (as Administrator):
Optimize-VHD -Path $Env:LOCALAPPDATA\Docker\wsl\data\ext4.vhdx -Mode Full
If the above command fails with
The system failed to compact 'C:\Users\Maxx\AppData\Local\Docker\wsl\data\ext4.vhdx':
The process cannot access the file because it is being used by another process. (0x80070020).
exit form Docker Desktop or stop services and tasks using that file:
net stop com.docker.service
taskkill /IM "docker.exe" /F
taskkill /IM "Docker Desktop.exe" /F
wsl --shutdown
I reclaimed 15Gb of 40Gb.
Origin of the solution.
You can just clean data from interface. Troubleshooting -> Clean/Purge data
Upgrading from WSL1 to WSL2 made it a bit messy, but resetting docker-desktop to its default setting and then purging data from WSL (using docker-desktop troublesshot) cleared it for me.
My Windows 8.1 just crashed. Now I have some files on my dist that are corrupted. This includes my vagrant machine index (Not shure if the naming is right but I know that it is this file -> C:\Users\USERNAME.vagrant.d/data/machine-index/index).
So There is a lot of binary or hexdecimal stuff in there (Again not shure because I don't deal with this stuff usualy so correct me if I'm wrong!) And Vagrant spits out the following message if I try to start everything after boot.
vagrant up returns this
The machine index which stores all required information about
running Vagrant environments has become corrupt. This is usually
caused by external tampering of the Vagrant data folder.
Vagrant cannot manage any Vagrant environments if the index is
corrupt. Please attempt to manually correct it. If you are unable
to manually correct it, then remove the data file at the path below.
This will leave all existing Vagrant environments "orphaned" and
they'll have to be destroyed manually.
Path: C:/Users/Username/.vagrant.d/data/machine-index/index
Same thing happened to me. So I just deleted the index file and the .lock file from the machine-index folder to get Vagrant working again.
When using Vagrant 2.2.5 in Windows 10, I had to navigate to /Users/{yourname}/.vagrant.d/data/machine-index and remove both index and index.lock, so rm index then rm index.lock.
Finally I navigated back to Homestead folder and ran vagrant up.
When accidentally my laptop crashed, I had the same vagrant issue (index) on my first attempt to run vagrant up.
The machine index which stores all required information about
running Vagrant environments has become corrupt. This is usually
caused by external tampering of the Vagrant data folder.
Vagrant cannot manage any Vagrant environments if the index is
corrupt. Please attempt to manually correct it. If you are unable
to manually correct it, then remove the data file at the path below.
This will leave all existing Vagrant environments "orphaned" and
they'll have to be destroyed manually.
Path: C:/Users/{user}/.vagrant.d/data/machine-index/index
Unfortunately my issue was not solved by deleting the index and index.lock files as the most voted up answer told. I rebooted my vm using virtualbox GUI (used as VM provider) and shown up the following message.
Entering emergency mode. Exit the shell to continue.
Type "journalctl" to view system logs.
You might want to save "/run/initramfs/rdsosreport.txt" to a USB stick or /boot
after mounting them and attach it to a bug report.
I realised that crash produced errors on VM's FS. So after searching and investigation I overcame that issue by executing the command below.
xfs_repair -v -L /dev/dm-0
Environment info: OS windows10, virtual-box 6.1, vagrant 2.2.7 and vm-os centos7
I have a Dlink NAS (dns-323) in RAID1 that I use to backup family photos, videos and some other data. I also manually rsync to a dedicated backup drive on a little Atom Linux box whenever we add a lot of new files to the NAS. I finally lost a drive on the NAS and through a misstep of my own, also lost the entire volume. No problem, that's what the backup drive is for. I used the same rsync command in reverse to restore files to the NAS after I replaced the bad drive and created a new RAID volume. This worked well, except that after the command finished, I noticed that it did not preserve timestamps. Timestamps were preserved in the NAS->backup direction, but not the backup->NAS direction.
I run the rsync command on the Atom Linux box with these options (this does preserve timestamps):
rsync --archive --human-readable --inplace --numeric-ids --delete /mnt/dns-323 /mnt/dlink_backup --progress --verbose --itemize-changes
The reverse command to restore the volume from the backup (which did not preserve timestamps) is very similar:
rsync --archive --human-readable --inplace --numeric-ids --delete /mnt/dlink_backup/dns-323/ /mnt/dns-323/ --progress --verbose --itemize-changes
which actually restores the files, but gives many errors like:
rsync: failed to set times on "/mnt/dns-323/Rich/Code/.emacs": No such file or directory (2)
I've been googling most of the afternoon and trying different things, but so far haven't solved my problem. I used the 'touch' command to successfully modify the times of one or two files on the NAS, just to prove that it can be done since I believe that is one thing that rsync must do. I've tried doing this as my user and as root. By this I mean that I've run sudo rsync ..... as well as rsync --rsync-path='/usr/bin/sudo /usr/bin/rsync' ..... where ..... is all of the previously mentioned parameters. My /etc/fstab has these entries for the NAS and the backup drive, respectively:
# the dns-323
//192.168.1.202/Volume_1 /mnt/dns-323 cifs guest,rw,uid=1000,gid=1000,nounix,iocharset=utf8,file_mode=0777,dir_mode=0777 0 0
# the dlink_backup drive
/dev/sdb /mnt/dlink_backup ext3 defaults 0 0
It's not absolutely critical to preserve timestamps if it just plain can't be done, but it seems like it should be possible - I'm just stumped.
Thanks in advance. Let me know if I can provide any additional information.
I've earned my "tumbleweed" badge as a result of this one. pats self on back
What I've learned:
My solution:
1) Removed the left hard drive from the dns-323, which is half of the RAID1 volume.
2) Mounted (ext3) this drive using a USB-to-SATA adapter to the machine where I run rsync.
3) Performed the rsync command for the restore outlined above. I removed the --delete option which really shouldn't be there and I added the option --size-only. The size-only option made it so that timestamps were essentially the only thing that got restored, since files had already restored properly.
4) Unmounted the left drive from the Atom machine and returned that drive to the dns-323, while also removing the right drive. The right drive needs to be removed so that the dns-323 recognizes that the RAID volume is degraded.
5) Re-add the right drive to the dns-323 and tell it to rebuild the RAID volume.
6) All timestamps are now good.
A possible alternate solution:
I've read enough about rsync and NFS/Samba/cifs now to understand that this problem is likely related to permissions on the NFS server (dns-323). Internally, the user/group ids in the dns-323 are 501/501. No permutation of how I mounted the dns-323 on the Atom box would allow rsync to properly set timestamps. I do believe that changing my user account on the Atom box to have uid/gid of 501/501 would have worked, though. My user had the default 1000/1000 and root had 0/0 IIRC.
Is there any way to restore a snapshot from inside a VBox guest machine?
I have a Windows machine that hosts numerous machines. Currently we are working with something using a Ubuntu guest and it is really painful to have to keep switching machines just to revert a snapshot.
What I had in mind is setting the machine to a "base" state and every time I want to go to that I just type some command like:
revertbase
Than the machine would restart in the previous snapshot and I would just need to restart ssh to continue.
You cannot snapshot a running machine, you have to freeze it before, so my guess is that the host itself cannot do that.
In the host machine, from command line you can do this using VBoxManage.
The file is located in
Program Files/Oracle/VirtualBox/VBoxManage.exe
and is used as a command-line interface with VirtualBox.
Using the command:
VBoxManage snapshot "MachineName" take SnapShotName
Them after that:
VBoxManage snapshot "MachineName" discardcurrent -state
To return to the last state, for more read the text bellow, to have easy acess to VBoxManage add it to your path:
PATH=%PATH%;c:\Program Files\Oracle\VirtualBox
Taken from: http://www.linux.com/news/enterprise/systems-management/8224-secrets-for-controlling-virtualbox-from-the-command-line
Managing snapshots
One of the most useful feature of virtualization software is its ability to take snapshots of VMs. It's always a good idea to take a snapshot of a VM before making changes to it. Snapshots help on the hardware level to recover a system that has been rendered unusable due to changes to the hardware configuration, and on the software level they protect against data loss due to accidental deletion or virus.
Taking a snapshot from the VirtualBox CLI is child's play. VBoxManage snapshot "Fedora" take snap1-stable-system takes the snapshot of a stable Fedora VM when everything is working perfectly. Saving a snapshot might take some time, depending on the VM and the resources on the host. To make sure you don't make changes to a system while a snapshot is being taken, VirtualBox grays out the whole VM interface, and you cannot use it until the snapshot has been saved.
With a stable snapshot in hand, go ahead and play with the system. If you get in trouble and your machine won't boot or starts behaving abnormally, you can revert to the snapshot of the stable machine. To do this, first power off the VM with VBoxManage controlvm "Fedora" poweroff, then revert to last snapshot with VBoxManage snapshot "Fedora" discardcurrent -state. If you have multiple snapshots, you can revert to the last but one snapshot with the -all switch instead of -state.
Of course when you revert to an older state, all the changes you made since that snapshot was taken are lost, including all configuration changes and changes to old and new files. You can work around this by specifying that your data should be stored on a "writethrough" disk, which behaves like a normal disk but isn't affected by snapshots. Put another way, when you take a snapshot, VirtualBox ignores the writethrough disk. You can store all your important data and files or your complete /home directory on that disk.
 
To add a writethrough disk, use the -type writethough option when creating a new disk with createvdi. You can also change a disk you created earlier and make it writethrough. To do so, first unattach it from the VM with VBoxManage modifyvm "Fedora" -hdb none, and then unregister it with VBoxManage unregisterimage disk fourgig (using the name of the disk on your system in place of fourgig). Now register it back again but as a writethrough disk with VBoxManage registerimage disk "fourgig" -type writethrough. Finally, attach it back to the VM using VBoxManage modifyvm "Fedora" -hdb fourgig.
Now you can safely save data on this disk, and no matter what state the VM is in, the data will always be safe. But remember not to revert back to a state that was saved before this disk was created; if you do, VirtualBox will simply delete the disk, becase it didn't exist in that state. Also, VirtualBox doesn't currently let you take a snapshot of a VM that has a writethrough disk attached, so you have to unattach a writethough disk before saving the state of the VM and then reattach it. I hope in upcoming VirtualBox versions the presence of a writethrough disk will have no influence on the snapshot process.
An updated answer. You still can't do it from the guest directly.
You could trigger the host to restart the guest by means of a shared drive/folder and a script running on the host which will reload the guest when a shared file is updated.
Included is my windows script to restart the guest. The commands as given by Canesin did not work for me. I have the following in a CMD file.
PATH=%PATH%;c:\Program Files\Oracle\VirtualBox
vboxmanage controlvm "DEMO" poweroff
timeout /t 10
vboxmanage snapshot "DEMO" restorecurrent
timeout /t 10
vboxmanage startvm "DEMO"