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'.
Related
I'm trying to build Superset locally using docker-compose.
After cloning the repository, I modify docker-compose.yml so that it builds images from local source code instead of pulling from Docker Hub. My modifications include:
In service db, change Postgres image version from image: postgres:14 to image: postgres:10 since the service cannot be built properly with Postgres 14.
In services superset, superset-init, superset-worker, superset-worker-beat and superset-tests-worker, change image: *superset-image to build: . so that Docker builds the application from local source code.
However, after running docker-compose build and then docker-compose up, I got the blank screen like this. I checked out the logs and found out that a lot of asset files are missing, for example /static/assets/images/loading.gif is missing which results in that blank screen.
What am I wrong or missing from my configuration steps? Please help me.
I finally figured it out, it's because the webpackage of the superset frontend is installed inside the container superset_node instead of while building it. That's why although the superset_node is built, we have to wait (in my case for about 15-20 more minutes) for the webpackage to be completely installed. Another point to note is that this installation takes up a lot of memory, so make sure you allocate enough RAM to it (in my case I allocate 16GB to Docker).
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.
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
I can't seem to ssh into any instances that are created from a snapshot of an openSUSE instance that's created within Google Cloud (ie: not from a snapshot created locally and then uploaded). I've tested this with three different openSUSE instances, 2 that I had been working on and one that I created only to test this on, and none have been able to produce snapshots that produce instances that allow ssh. To be clear, the instances created from the snapshots start up perfectly fine and show no issues from the console, but neither the console's built in ssh nor any other ssh client (putty, mobaxterm) gets anything more than a time out error. I have successfully created instances from both a Windows and Debian snapshots that I have created myself, so I'm confident it's an issue with the specific OS.
Steps to reproduce:
Create an instance based off of the openSUSE image
Create a snapshot based off of the instance you just created
Create an instance based off of the snapshot you just created
Attempt, and fail, to connect to the instance via ssh
Any help with this would be much appreciated, and thank you very much in advance.
I was able to reproduce your issue. I'll report it to Google. If your run the command
gcloud compute instances get-serial-port-output <your-new-instance>
You will notice that there's an error indicating that couldn't find the disk.
SUSE has fixed the issue yesterday on SLES distros. The following new images are now available (bug-exempt):
sles-11-sp3-v20150310
sles-12-v20150310
We are still working on a fix to openSUSE, and we still don't have a fix for existing instances.
A procedure to address running instances has been posted:
https://forums.suse.com/showthread.php?6142-Image-from-snapshot-will-not-boot&p=26957#post26957
The above post contains all the details, the procedure below addresses the question about "what to do with running instances."
SUSE Linux Enterprise Server 11 SP3 (sles-11-sp3)
1.) Edit /etc/sysconfig/bootloader
In the "DEFAULT_APPEND" assignment replace "root=/dev/disk/by-id.." with "root=/dev/sda1". Reform the same substitution for the "FAILSAFE_APPEND" assignment.
Add NON_PERSISTENT_DEVICE_NAMES=1 to the end of the line, after "quiet"
2.) Edit /etc/fstab
Replace "/dev/disk/by-id..." with "/dev/sda1"
3.) Edit /boot/menu.lst
Replace "root=/dev/disk/by-id.." with "root=/dev/sda1" and "disk=/dev/disk/by-id/..." with "disk=/dev/sda" in both options.
Add NON_PERSISTENT_DEVICE_NAMES=1 to the end of the line starting with "kernel"
4.) Reboot the instance
5.) Execute mkinitrd
6.) Edit /etc/udev/rules.d/70-persistent-net.rules (if it exists)
Remove the mac address condition, "ATTR{address}==.....", from the rules.
SUSE Linux Enterprise Server 12 (sles-12)
1.) Edit /etc/sysconfig/bootloader
In the "DEFAULT_APPEND" assignment replace "root=/dev/disk/by-id.." with "root=/dev/sda1" and "disk=/dev/disk/by-id/..." with "disk=/dev/sda". Perform the same substitution for the "FAILSAFE_APPEND" assignment.
Add NON_PERSISTENT_DEVICE_NAMES=1 to the end of the line, after "quiet"
2.) Edit /etc/fstab
Replace "/dev/disk/by-id..." with "/dev/sda1"
3.) Edit /etc/default/grub
In the "GRUB_CMDLINE_LINUX_DEFAULT" assignment replace "root=/dev/disk/by-id.." with "root=/dev/sda1" and "disk=/dev/disk/by-id/..." with "disk=/dev/sda".
Add NON_PERSISTENT_DEVICE_NAMES=1 to the end of the line, after "quiet"
4.) Create a new grub configuration (SLES 12)
export GRUB_DISABLE_LINUX_UUID=true
grub2-mkconfig > /boot/grub2/grub.cfg
5.) Execute mkinitrd
6.) Edit /etc/udev/rules.d/70-persistent-net.rules (if it exists)
Remove the mac address condition, "ATTR{address}==.....", from the rules.
A new openSUSE 13.2 image has been published that addresses the issue as well. New instances started from opensuse-13-2-v20150315 will work with no issues with the snapshot feature in GCE. For running instances use the process outlined for SUSE Linux Enterprise 12, that should work. I did not test the procedure on openSUSE.
I'm following these steps outlines on this link, however when I try to start the server nothing happens nor can I connect to anything from the client. Does anyone know how to run this?
when I try from a command prompt instead of double clicking the redis-server.exe I get this message
[11868] 23 Jul 11:58:26.325 # QForkMasterInit: system error caught. error code=0
x000005af, message=VirtualAllocEx failed.: unknown error
http://bartwullems.blogspot.ca/2013/07/unofficial-redis-for-windows.html
The easiest way to install Redis is through NuGet:
Open Visual Studio
Create an empty solution so that NuGet knows where to put the packages
Go the Package Manager Console: Tools –> Library Package Manager –>Package Manager Console
Type Install-Package Redis-64
image
Go to the Packages folder and browse to the Tools folder. Here you’ll find the Redis-server.exe. Double click on it to start it.
Redis is ready to use and start’s listening on a specific port(6379 in
my case)
image
Let’s open up a client and try to put a value into Redis. Start Redis-cli.exe. It already connects to the same port by default.
image
Add a value by executing following command:
image
Read the value again:
image
Try to run with redis-server --maxheap 4000000
Miguel is correct, but it is not that simple. To start redis-server either as a service or from the command prompt, the amount of available RAM and disk space must be sufficient for Redis to run as configured.
Now, if no configuration file is specified when running Redis, it will use the default configuration values. All of this is documented in the redis.windows.conf file as well as in the document "Redis on Windows.docx" (both deployed with the redis installation).
In my experience, errors when starting Redis usually come from lack of available resources (RAM or disk space) or some incorrect configuration of maxhead or maxmemory parameters.
To troubleshoot this kind of behavior, check your system's available resources and try running redis-server from the command line varying the parameters maxmemory, maxheap, and/or heapdir. The loglevel parameter set to verbose might also help diagnosing the issue.
Regards