Unable to delete Snapshot from Snapshot Manager in Virtual machine - virtual-machine

I have a Virtual Machine with many snaps.
When I am going to delete any of the snap from the snapshot manager it shows error as The Virtual machine is a Template and does not allow me too delete the snap.
Can any one tell me why this has been happened?
There is also one problem, in Snapshot manager if we check the checkbox for the Show AutoProtect Snapshots it shows too many hidden shapshots.
How I can delete those Snapshots?
any type of suggestion or help can be appreciated.

I happened to stumble over this issue today and tried to head over the VMware KB article but the page is not there.
Updating the original question in case someone encounters this same issue.
Presuming the VM in question is already shutdown when you try to delete the snapshot from snapshot manager. Go over and open up the VMX file of the VM in your editor and remove the line which says templateVM="true" . Save the file.

The following kb should assist you in changing from a template vm http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1004538

Related

Oracle VM -- Metasploitable Issue "Can't Overwrite Medium..."

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.
]

Docker build fails always with error hcsshim::PrepareLayer - failed failed in Win32: Incorrect function. (0x1) Windows Containers

Steps to reproduce are very easy.
Create a Dockerfile.
My Dockerfile has many more lines, but I have trimmed them so we can focus in the source of the problem.
Said that, these two lines alone (without anything more) show the problem.
FROM microsoft/iis
SHELL ["powershell", "-Command", "$ErrorActionPreference = 'Stop'; $ProgressPreference = 'SilentlyContinue'; $VerbosePreference = 'Continue'; "]
Run docker build . and you get hcsshim::PrepareLayer - failed failed in Win32: FunciĆ³n incorrecta. (0x1).
Windows 10 Pro 1909 (but it happened too in 1903)
Docker version: 2.1.0.5
Engine: 19.03.5
Machine: 0.16.2
I have found the solution to the problem.
Reading all the https://github.com/docker/for-win/issues/3884 bug, some have found a simple solution: rename C:\windows\system32\driver\cbfsconnect2017.sys so it isn't loaded the next boot.
Disabling that driver enables me to do a docker build for the first time in windows containers in almost a year.
In my case Box Sync was the one using that driver.
EDIT: #GustavoTM have found that pCloud raises the same problem.
EDIT2: #VonC have noticed that some people in the issue in GitHub has solved it deleting this other file: C:\Windows\System32\drivers\cbfs6.sys. I haven't tried that, but i put it if it helps others.
The good thing is that I don't need to uninstall Box, but only rename that file.
This is still an issue (still open) with Win10.
Looks like uninstalling cloud storage providers with file system filters like Dropbox, Box, etc. as a workaround is an option for some users.
Deinstall cloud storage providers or virus scanners; if you identify which one is not working please share in https://github.com/docker/for-win/issues/3884
In my case was the problem similar but the file cbfs6.sys was placed somewhere in the rest of uninstalled application Jungle disk, somewhere in the folder c:\Program files\Jungle disk .... It's part of Callback File System signed by EldoS Corporation.
The folder could be rename only and not delete directly. So I could delete its immediately after the PC restart, before running the Docker. So it could be delete during the Docker service restart too.

Creating a snapshot for a proxmox VM is not possible either in the GUI or CLI

I'm trying to make a snapshot of one of my VMs via the GUI but the button to creat the snapshot is greyed out, so I wanted to try and do it using the CLI so I could see any helpful output and I got this:
pct snapshot 106 "testing"
Configuration file 'nodes/pve01/lxc/106.conf' does not exist
the list of my VMS:
qm list
VMID NAME STATUS MEM(MB) BOOTDISK(GB) PID
106 TestingServer running 1024 32.00 23131
I'm not sure what's this about so I was trying to see if somebody here could please give me a hand, I would appreciate it.
I have the same issue on some of the volumes I've attached. So basically, there's a very specific requirement for the storage type you need to have in order to make a snapshot of VM. The list below has the requirements and you can find more information here https://pve.proxmox.com/wiki/Storage#_storage_types
Hope this helps.
You can check the storage type by going to Datacenter > Storage
Once storage is created you cannot change the type of that storage.
The command 'pct snapshot' is a command to snapshot a container (not a QEMU VM). The error is indicating that it can't find a container (LXC) with VM ID 106:
Configuration file 'nodes/pve01/lxc/106.conf' does not exist
The LXC in the path here indicates that it is looking for an LXC container. Your command 'qm list' lists QEMU VMs (not containers). So you are using the wrong command.
You need 'qm snapshot' instead of 'pct snapshot'.

Expired time for acquiring lock pentaho

I'm using pentaho BI (spoon) and I have a problem with it.
At each action (open job/transformation or save for example) it show this window
http://i.stack.imgur.com/bqmZQ.jpg
now I can't open existing transformation. Does anyone know this issue?
I know this is an old post, but the problem is still current (version 8.2 CE), and I was unable to find any help (other than the workaround to delete the .lock files, but this only solves it for a few minutes, possibly even less).
I had exactly the same problem, it basically rendered Spoon useless. In my case, the culprit was the antivirus program. I noticed it only because I installed the AV after I used Spoon for some time. I just removed the AV (and installed another one) - no more problems.
It seems that your repository is having some issue in connecting.
Try checking the repo. connection and also check for the permission of accessing the repo.
I faced a similar issue and was able to resolve it by deleting the lock file under
D:\Pentaho-ce\file-repository\ETL\.meta\metastore\.lock
(local-repository root)\.meta\metastore\.lock
Kettle - Spoon version 5.4.0.1-130
I was also facing a similar issue and was able to resolve it by deleting the lock.
Pentaho tool creates .pentaho directory in the home directory.
inside .pentaho delete .lock from
.pentaho/metastore/.lock
and also delete .lock file
/home/pdi-ce-9.1.0.0-324/data-integration
restart your pentaho tool.
hope above solution works for you.
I faced a similar issue and was able to resolve it by deleting the lock file under C:\Users\myuser.pentaho\metastore

Oracle virtual box inaccessible

I am using Oracle Virtual Box version 4.2.16 r86992. Everything was fine until yesterday shutdown.
Today, it shows inaccessible and throws this error:
Runtime error opening C:\Users\xxxxxx\VirtualBox VMs\vBoxxxxXubuntu_Beta\vBoxxxxXubuntu_Beta.vbox for reading: -102 (File not found.).
D:\tinderbox\win-4.2\src\VBox\Main\src-server\MachineImpl.cpp[725] (long __cdecl Machine::registeredInit(void)).
It's good to restore this to working, It would save lot of time and restore configuration settings and data. Thanking your support.
This normally happens if the host OS crashes or you pull the plug on it, leaving the .vbox file unsaved.
In the location:
C:\Users\xxxxxxx\VirtualBox VMs\vBoxxxxXubuntu_Beta\
you should find two files:
vBoxxxxXubuntu_Beta.vbox-prev
vBoxxxxXubuntu_Beta.vbox-tmp
Copy vBoxxxxXubuntu_Beta.vbox-prev to vBoxxxxXubuntu_Beta.vbox.
Select vBoxxxxXubuntu_Beta.vbox, in the VBox manager, right click, and then left click on refresh.
Observe that it now shows Powered Off.
Now you are good to go.
Based on my experience, I was on Windows 7 and running Ubuntu 14.04 as guest OS on Virtual Machine.
Go to your Virtualbox folder (in my case):
C:\Users\Dev12\VirtualBox VMs\Ubuntu
You'll see files with extensions: Ubuntu.vbox-tmp or Ubuntu.vbox-prev
Remove -tmp from file name Ubuntu.vbox-tmp so that it reads as Ubuntu.vbox
Exit from Virtual Machine and start it again.
You should now see error gone away.
The virtual box files with extension .vbox contain metadata the virtualbox hypervisor requires to resolve the guest virtual OS' configuration.
If the main .vbox file is corrupted (i.e. reporting that it is empty) then use the backup .vbox-prev file to recover the contents of the original file.
Do this by renaming the empty .vbox files a temporary name (e.g. rename originalVM.vbox to originalVM-empty.vbox).
Then make a copy of the backup file originalVM.vbox-prev, where the copy will have the same name as the original but with the word "copy" appended to it (i.e. originalVM.vbox-prev is renamed to originalVM (copy).vbox-prev).
It is important to retain the original backup .vbox-prev file it should not be altered or itself renamed.
Now go rename the copy of the newly created .vbox-prev file originalVM (copy).vbox-prev to the original name of the empty .vbox file and be mindful to also change it extension from .vbox-prev back to just .vbox.
That is rename originalVM (copy).vbox-prev back to originalVM.vbox. Now that this is done you may add the .vbox file (guest os) back into the VBOX hypervisor. This will recover the state and snapshot of the "inaccessible" guest VM. Now delete the original empty .vbox file.
I've faced the same issue using CentOs 6.8 on a VirtualBox 5.1 installed in Windows 7 and AjayKumarBasuthkar's solution worked perfectly for me:
I went to C:\Users\\VirtualBox VMs\CentOS6.8
Made a copy of the file CentOS6.8.vbox-prev and gave it the name of CentOS6.8.vbox
Went to the VirtualBox GUI, right-clicked the VM instance and hit refresh
The CentOS instance went from the State Inaccessible to Powered Off
VirtualBox 4.3 is released and could it be that you've updated or there was some issues while updating?
In any case if you are not able to bring up the Virtualbox, remember to backup the VirutalBox VMs folder and going for a fresh install should be the best way forward.
I faced the same problem and I resolved by doing following in Oracle Virtual box 4.3.28 with Ubuntu 14.04 LTS, when Virtual box VM was closed.
Removed ubuntu.vbox to another folder outside virtual box folder
removed -prev from file ubuntu.vbox-prev
start oracle virtualbox, it works excellent.
On a Windows 7 Host, I found that Daemon Tools service had a hold on the file.
The solution was to uninstall Daemon Tools, but I suspect if you stop the service and remove the file association, you would be sorted.
The other issue might be that if your Virtual Machine was on an external hard drive, it is possible that the drive letter has changed. If so, go to Computer Management, and select the hard drive and right click to change the drive letter and save (Note that this is for Windows).
This is going to sound stupid but try to reinstall VB. It may work.
I am adding one critical and important comment to the previous great answers. Make sure that the original .vbox file is corrupted and empty before you copy the content from the.vbox-prev file. If it is not the case and you find it with lines and readable content, don't replace the content of the .vbox.
Changes made to the VM directly before the VM got inaccessible might not be updated in the .vbox-prev backup file . The changes could not be synced with those changes before the OS upgrade or system changes that led to the inaccesable issue.
If you find your VM not accessible after an OS upgrade or system change, first check the.vbox file if it is still readable by a text editor and it has lines. Then you just need to delete the VM from the VirtualBox manager list(just remove the appliance from the list and don't remove files) . Then reopen the.vbox file and it should work perfectly.
If the original.vbox file is corrupted or empty when you open it with a text editor, then and only then, you can copy the content from the .vbox-prev and follow the instructions highlighted.
This was my experience, and I wanted to share it with you to avoid losing some last minute changes before the OS upgrade or crash.