Why so many "Virtual Disk" .vmdk files got created under ""Documents/Virtual Machines.Localized/Windows7 x64.vmwarevm/", now Im left with no space, unable to boot guest windows7 OS
Please click here to view the screenshot.
Under the VM settings, open the hard disk then expand advanced options, you are probably splitting the vmdk into multiple files. You can also choose to pre-allocate the space or not.
You can move the vm folder to another drive and register once more in fusion, should you have space on another drive.
I always keep my vdisks as one file and don't pre-allocate the space (thin provisioning).
Related
I have a compute engine in google cloud and i am using it for a while
But for someday, I am getting the "-bash: cannot create temp file for here-document: No space left on device" while pressing the tab in keyboard for auto file/folder selection. I have done some research on this, and found out that the space in the root file execute this error. But the server is showing free spaces with command df -h
Here is the screenshot
Is there anyone having the issue?
Thank you in advance..
A resolution to this issue would be to resize the persistent disk guide to resize, keep in mind to backup guide to snapshot the disk, by creating a snapshot, in order to protect it against any unforeseen circumstances that may appear, especially if you have no recoverable files on the disk.
Also, another option would be to add another disk to the VM guide to add disk.
If the resizing process finishes successfully, it is advised to restart the machine and get the existing files out, because even if the workaround is feasible.
I currently have a GCP VM where I tried to install something and there was a no memory left error on Ubuntu. I tried opening the SSH again and it is not working.
P.S there is no problem with firewall/connection.
I just want a way to download the files that I had stored in the VM. Is there a way to do this without accessing the Terminal?
If you are not able to login through serial console, then the only option left would be to retrieve the data from your OLD VM by creating a new VM.
You can follow the steps below to copy the data from the affected(OLD) VMs disk.
1 Create a snapshot from the boot disk of the OLD VM
2 Create a new VM. As a boot disk, you should use a Google public
image (important- do not use the snapshot you created).
3 Once that instance is created, try to SSH into it just to test if
you are able to access it. There should be no issue at this point with
this VM instance, as this is a new instance using a fresh operating
system.
4 In the newly created instance, click on the instance name (in the
Console), and then click ‘Edit’ at the top of the page to edit the
machine.
5 In the ‘Additional Disks’ section, click ‘Add item’.
6 In the ‘Name’ drop-down select ‘Create disk’. In the window that
opens add a name for the disk, and in the ‘Source snapshot’ drop-down
select the snapshot you created in Step 1. Now Click ‘Create’
7 Click ‘Save’ to save the instances new configuration.
8 Please SSH into the new instance, and run command $lsblk . You will
be able to see the new disk and partition added (It will most probably
be named sdb1 but you should check this and take note).
9) Please run the following command which will create a mount point at
/mnt/newdisk and then mounts the additional disk partition to that
mount point. Note- substitute /dev/sdb1 in the below command with the
name of the partition if it is different.
$ sudo mkdir /mnt/newdisk | sudo mount -o discard,defaults /dev/sdb1
/mnt/newdisk
The snapshots file system will now be mounted at /mnt/newdisk.
You should now be able to navigate the directories and retrieve any data.
I hope this helps you.
The description and results of your problem do not make sense. However, lets assume that your instance is out of memory and you cannot connect to the instance with SSH.
Reboot the instance and try again. Installing software might cause an out of memory issue. Rebooting should correct this.
Launch the instance with a larger machine type that has more memory. If this is a memory size problem, this will correct it.
Detach the instance's disk and attach to another instance that you can connect to. Mount the file system and copy off the files.
However, if instead your problem is out of disk space, this makes more sense.
Resize the instance disk. In the Google Cloud Console, go to Compute Engine -> Disks. Click on the disk for your instance. Click EDIT. Under Size enter a new larger disk size. Now launch your instance. For most operating systems (Ubuntu, Debian, etc.) the OS will automatically resize the root file system. I wrote an article that covers this in detail.
If you can't connect to the instance you always can take a snapshot of the disk and then create a copy to mount it in a new instance to recover the data from there.
I spun up a new VM which gave me a 128GB OS disk. I expanded the size of that to 512GB, which can be seen below:
However, when I go into my VM, bring up File Explorer and look at my hard disk capacity, I still see the same original size:
Am I missing something?
You need to start the VM from the portal and connect to the VM. Go to Disk Management, you will notice that the disk size has changed to 512 GB now. Right-click on the volume and select 'Extend Volume'. Follow the on-screen steps to extend the volume.
After that, you will see the expanded disk. Refresh, go back to C:\ to verify it.
I accidentally didn't change the target location for a virtual box I created out of an .ova file and now I'm running low on storage on the drive where the VirtualBox VMs folder is located. My question is, is it safe to just cut and paste the folder to a destination on my mass storage drive or do I have to follow any specific rules?
Thanks in advance.
Yes it is safe. Your VM's virtual hard disk is the largest file in your VM folder. After moving the files, your existing VM will throw error. You can create a new VM and when it asks for hard disk, click "use existing.." option and select your vm hard disk file from new location
Heres what happened.
I had a snapshot on which I was working from within a linux VM. A friend requested a clean VM as a clone of mine. So I closed / shutdown my running VM, made a copy of the Disk1.vdi along with the snapshots ({uuid}.vdi). Then I restarted the VM and did merged snapshots, deleted my home directory and made a tar+bz2 for my friend.
Then after I restored my backups, I am not able to mount my snapshot. The VM seems to boot from my version before snapshot. I cant seem to find a way to mount back my snapshot.
Any idea how to make VirtualBox see the snapshot and mount it?
I am not an expert but have coincidentally done some investigation into just this topic. You indicated that you backed up your disks (VDI and snapshots) before making changes but you did not back up the VM itself (the XML file). So you have created an incompatibility by restoring VDI and snapshots to the changed VM (that still thinks there is only a merged disk with no snapshots). Without a backup of the original VM file itself you may be out of luck. (Please see Cloning a VM With Multiple Snapshots for supporting evidence.)
You can get back to work the snapshot, tricky but may try this (with no Virtual Machine running):
Open VirtualBOX GUI
Go to manage disks
Detach your main VDI from your Virtual machine.
Set it as INMUTABLE.
Reattach the main VDI from your Virtual machine
Exit from ALL virtualbox processes
Get the uuid of your snapshot VDI with VBoxManage showhdinfo, the one you want to use not the one created when making immutable the main VDI
Now edit the VBOX file with text editor and look for the path of the snapshot that was created so you know where to go to delete that small file, do not close the text editor
Delete that small snapshot vdi file
Now, on the text editor, replace the uuid of the snapshot and the path to the snapshot vdi to point to your snapshot vdi file
Save the VBOX file and close the text editor.
For future times: Remember to also backup the VBOX files too.
The trick is based on making VirtualBox create a fake snapshot file (a file that you will manually delete) and replace the references added to the vbox file with your snapshot, but take take to also replace the uuid of the snapshot file with the correct one, for that you can get it with showhdinfo.
Be warned, the snapshot uuid on the VBOX file appears on to sections, the register (near the beginning) and the attached section (near the end), you must replace both, you can use search & replace the newly uuid with yours.
Hope it will work for you; i never do snapshots of a virtualbox, I prefer the immutable way (but that is only for just one level).