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
Related
I'll give a bit of a background as to the setup we have and why. Currently myself and a friend want to collaborate on an Unreal Engine Project. To do this I've set up an Amazon Lightsail Instance with Windows Server running. I've then installed Perforce onto this Server and added two users. Both of us are able to connect to this server from our local machines (great I thought!). Our goal was to attach two 'virtual' disks of 32gb to this server via Lightsails Storage option. I've formatted these discs and they are detected as Disk D and E on the Server. Our goal was to have two depots, one on Disk E and one on Disk D, the reason for this being the C disk was only 20gb (12gb Free after Windows).
I have tried multiple things (not got much hair left after this) to try and map the depots created to each HDD but have had little success and need your wisdom!
I've followed both the process indicated in this support guide (https://community.perforce.com/s/article/2559) via CMD as well as changing the depot storage location in P4Admin on the Server via RDP to the virtual disks D and E respectively.
Example change is from //UE_WIP/... to D:/UE_WIP/... (I have create a folder UE_WIP and UE_LIVE on each HDD).
When I open up P4V on my local machine I'm able to happily connect (as per screenshot) and set workstation to my local machine (detects both depots). This is when we're getting stuck. I then open up a new unreal engine file and save the unreal engine file to the the following local directory E:/DELETE/Perforce/Test/ and open up source control (See image 04). This is great, it detects the workspace and all is connecting to the server.
When I click submit to source control I get the following 'Failed Checking Source Control' when I try adding via P4V manually marking the new content folder for add I get the following 'file(s) not in client view.
All we want is the ability to send an Unreal Engine up to either the WIP Drive Depot or the Live Drive Depot. To resolve this does it require:
Two different workstations (one set up for LIVE and one for WIP)
Do we need to add some local folders to our directory? E:/DELETE/Perforce/UE_WIP & E:/DELETE/Perforce/UE_LIVE?
Do we need to tweak something on the Perforce Server?
Do we need to tweak something in Unreal Engine?
Any and all help would be massively appreciated.
Best,
Ben
https://imgur.com/a/aaMPTvI - Image gallery of issues
Your screenshots don't show how (or if?) you set up your local workspace (i.e. the thing that tells Perforce where the files are on your local workstation).
See: https://www.perforce.com/perforce/r13.1/manuals/p4v/Defining_a_client_view.html
The Perforce server acts as a layer of abstraction between the backend storage (i.e. the depots you've set up) and the client machines where you actually do your work. The location of the depot files doesn't matter at all to the client (any more than, say, the backend filesystem of a web server matters to your web browser); all that matters is how you set up the workspace, which is a simple matter of "here's where my local files are" (the Root) and "here's how my local paths map to depot paths" (the View).
You get the "file not in view" error if you try to add a local file to the depot and it's not in the View you've defined. The fix there is generally to simply fix the Root and/or View to accurately describe where you local files are. One View can easily map to multiple depots (as long as they're on a single server).
(edit)
Specifically, in your case, all of the files you're trying to add are under the path:
E:\DELETE\Perforce\Test\Saved\...
Since you've set up your workspace as:
Client: bsmith
Root: E:\DELETE\Perforce\bsmith
View:
//WIP/... //bsmith/WIP/...
//LIVE/... //bsmith/LIVE/...
then your bsmith workspace consists of these two local paths:
E:\DELETE\Perforce\bsmith\WIP\...
E:\DELETE\Perforce\bsmith\LIVE\...
The files you're trying to add aren't even under your Root, much less under either of the View mappings. That's what the "not in client view" error messages mean.
If you want to add the files where they are, modify your Root and View so that you define your workspace as being where your files are; if you want to have the files in one of the local directories above that you've already defined as being where your workspace lives, you'll have to move them there. If you put your files in bsmith\WIP, then when you add them they'll go to the WIP depot; if you put them in bsmith\LIVE, then they'll go to the LIVE depot, per your View.
Either way, once they're in your workspace, you can add them to the depot. Simple as that!
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.
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).
I have the following problem:
There two separate vCenters (ESXi). They cannot see each other or communicate in any way.
I can create a Clone of a VM in vCenter1 but then I want to move that Clone in vCenter2.
Is there a way that I can copy the Cloned VM (files) on an external HDD and move them in the other vCenter?
I've figure it out the solution to my problem:
Step 1: from within the vSphere client, while connected to vCenter1, select the VM and then from "File" menu select "Export"->"Export OVF Template" (Note: make sure the VM is Powered Off otherwise this feature is not available - it will be gray). This action will allow you to save on your machine/laptop the VM (as an .vmdk, .ovf and a .mf file).
Step 2: Connect to the vCenter2 with your vSphere client and from "File" menu select "Deploy OVF Template..." and then select the location where the VM was saved in the previous step.
That was all!
Thanks!
Yes, you can do this.
Copy all of the cloned VM's files from its directory, and place it on its destination datastore.
In the VI client connected to the destination vCenter, go to the Inventory->Datastores view.
Open the datastore browser for the datastore where you placed the VM's files.
Find the .vmx file that you copied over and right-click it.
Choose 'Register Virtual Machine', and follow whatever prompts ensue. (Depending on your version of vCenter, this may be 'Add to Inventory' or some other variant)
The VM registration process should finish with the cloned VM usable in the new vCenter!
Good luck!
For moving a virtual machine you need not clone the VM, just copy the VM files (after powering the VM off) to external HDD and register the same on destination host.
A much simpler way to do this is to use vCenter Converter Standalone Client and do a P2V but in this case a V2V. It is much faster than copying the entire VM files onto some storage somewhere and copy it onto your new vCenter. It takes a long time to copy or exporting it to an OVF template and then import it. You can set your vCenter Converter Standalone Client to V2V in one step and synchronize and then have it power up the VM on the new Vcenter and shut off on the old vCenter. Simple.
For me using this method I was able to move a VM from one vCenter to another vCenter in about 30 minutes as compared to copying or exporting which took over 2hrs. Your results may vary.
This process below, from another responder, would work even better if you can present that datastore to ESXi servers on the vCenter and then follow step 2. Eliminating having to copy all the VMs then follow rest of the process.
Copy all of the cloned VM's files from its directory, and place it on its destination datastore.
In the VI client connected to the destination vCenter, go to the Inventory->Datastores view.
Open the datastore browser for the datastore where you placed the VM's files.
Find the .vmx file that you copied over and right-click it.
Choose 'Register Virtual Machine', and follow whatever prompts ensue. (Depending on your version of vCenter, this may be 'Add to Inventory' or some other variant)
Copying the VM files onto an external HDD and then bringing it in to the destination will take a lot longer and requires multiple steps. Using vCenter Converter Standalone Client will do everything for you and is much faster. No external HDD required. Not sure where you got the cloning part from. vCenter Converter Standalone Client is simply copying the VM files by importing and exporting from source to destination, shutdown the source VM, then register the VM at destination and power on. All in one step. Takes about 1 min to set that up vCenter Converter Standalone Client.
You don't have to export your VMs at all. You can move the VM and clone to a TAXI host in vCenter 1. Then add the host to vCenter 2, and vMotion away whatever VMs to other hosts previously managed by vCenter 2. When done, you can add the TAXI host back to vCenter 1.
If you'd like to do this using the command line, you can do this if you have ESXi 6.0 (or possibly even ESXi 5.5) running, by using govc, which is a very helpful utility for interacting with both your vCenter and its associated resources.
Depending on your setup, you can
# setup your credentials
export GOVC_USERNAME=YOUR_USERNAME GOVC_PASSWORD=YOUR_PASSWORD
govc export.ovf -u your-vcsa-url.example.com -vm VM_NAME -dc VMS_DATACENTER export-folder
Then, you'll have your VM VM_NAME exported in the folder export-folder. From there, you can then
govc import.ovf -u your-other-vcsa-url.example.com -vm NEW_VM_NAME -dc NEW_DATACENTER export-folder/VM_NAME.ovf
That'll import it into your other vCenter. You might have to specify -ds NEW_DATASTORE too, if you have more than one datastore available, but govc will tell you so if you need to.
The commands above require that govc is installed, which you should, because it's far better than ovftool either way.
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).