A non-changeable VMWare image - vmware

I know the title is a bit weird, but I was unable to think a better one.
I wasunsuccessful in looking (googling) for creating a non-changeable VMWare image. I am not sure if this is even possible or not? Well the idea is that after VMWare restart I always have the same state.
Does anyone have any idea? Thanx in advance and hope it was not a completely stupid question.

Assuming you mean that when you power off your VM you want it to revert back to a known state and lose the latest changes, then this is possible with VMWare Workstation and I suspect other versions too.
You need to get the VM to the state you want to roll back too, shut it down and take a snapshot of this state.
You can now change the snapshot settings of the VM (VM->Settings->Options->Snapshots I think, but I'm not in front of VMWare at the moment, so may be wrong). Now you can set the VM to "When Powering Off: Revert To Snapshot". Now, every time the VM is powered down, it should revert to your known "baseline".

The only way I can think of you being able to do this Gico is that if you have a snapshot of the VM in whatever state you want, then revert to that snapshot whenever you need to, after a power down. This is definetly possible if you are using vSphere, not sure about the rest of VMware's products.
To do this in vSphere, get the machine in to the state you want, right click the VM in the vSphere Management console/ vCenter, select 'Snapshot -> Take Snapshot'. Then in the same snapshot menu use 'Snapshot Manager' to revert to that snapshot whenever you need to.
Maybe a way of reverting the snapshot automatically is described at this link:
http://www.vmware.com/support/ws5/doc/ws_preserve_sshot_revert_or_goto.html
Look in the Reverting at Power Off section.
It is possible to use 'Revert at power off' in VMware player too.

Related

Browser drops connection during model training

I am currently trying to go through a fairly long hyperparameter grid search (4-5 hours) and I keep having issues with Jupyter Lab (or haven't figured out something yet) on a gcp notebook instance. The browser connection to the notebook keeps dropping, whereas the training process continues just fine. When it finishes training process, there's nowhere to write the output as the browser connection to the notebook has already dropped.
How can I keep that connection alive or make sure the output gets written into the notebook even if my laptop gets turned off/gets turned off?
There are multiple problems that may be affecting your notebook. It can be a GCP issue, a network issue... Therefore, you need to provide more information in order to diagnose what is happening. I would recommend you to open a ticket with GCP or Jupyter support to conduct a more thorough investigation as it can be something difficult to diagnose and they will have more tools to do it. Also, what #Joaquim suggested seems like a good workaround for the moment. Anyhow, I have gathered several troubleshooting steps that you can follow to find if it is one of this recurrent issues the one that is affecting you:
According to this Jupyter Notebook document, there is a ‘shutdown_no_activity_timeout’ option. The default value is ‘0’ that disables this automatic shutdown. The option might be overridden on ‘jupyter_notebook_config.py’ file. You may follow these steps to confirm it:
Click on the instance name of in which your Notebook is running on the AI Platform Notebooks page.
Remote access it by clicking “SSH”
Run this on the shell to confirm the existence of the overriding:
ls /home/*/.jupyter/jupyter_notebook_config.py
Run this command to confirm if the shutdown_no_activity_timeout option is doing the overriding:
cat /home/*/.jupyter/jupyter_notebook_config.py | grep shutdown_no_activity_timeout
Switch the option to ‘0’ if it is set to a different value, and reset the Notebook instances on this page to apply the change.
According to this other document, it might fail to connect when behind a proxy. You can try to disable your browser’s proxy settings.
You can also try to change the Jupyter port. On this Jupyter issue, the customer insists that his disconnection problem was gone after changing it. If you are using Chrome browser, could you please open the Inspect panel (Ctrl+Shift+I) and compare your connection symptoms with this image? If you get similar errors, you may try to change the port (c.NotebookApp.port).

Not able to run cell on a jupyterlab notebook Google cloud ai platform

I am running 2 instances under Google AI Platform, which basically launches 2 VM instances to run jupyter lab. I have been happily making notebooks on both VMs. I shutdown both VMs for the day...
What's strange is that next morning, notebook from one VM will launch but when I run any cell containing simple things like "import pandas", it never return result and hang the whole thing (with a * where the cell # would have generated). I create a whole new notebook and just do a simple print("hello"). it also never returns. I restarted the instance a few times and still doesn't work. What I noticed is the "dot" on the top right corner is filled black. I think it should be white when the kernel is restarted. So there could be a problem with the kernel.
Any ideas what could go wrong? I don't even know where to debug this. The strange thing is the other VM still worked. I don't want to do anything drastic like re-creating a new VM, since I like to be able to fix this for a known cause.
Anyone out there experienced same thing?
In case you didn't attempt this, I would try refreshing the notebook window after restarting the machine.

VirtualBox Snapshot - How to stop them to grow and take more and more space?

I'm using Genymotion with Oracle VirtualBox, however i do have 250 GB SSD and i'm facing an issue with ( Snapshots ) I googled & searched here, I couldn't find any possible way to disable Auto snap-shots, as i don't need it.
Thanks
When you deploy a new Genymotion virtual device, a snapshot called factory-backup is automatically created so that paid users can reset the device to the factory state via the Launcher GUI. If you don't want this snapshot, then just use VirtualBox Manager directly to delete it once the device is deployed. From the Manager interface, with the VM in question selected, click on Snapshots in the upper right corner, then select factory-backup and hit the delete button. As far as I can tell, there is no provision for disabling this initial snapshot creation via the Genymotion Launcher.
In my experiences, Genymotion does not create further snapshots during the lifetime of a virtual device, only upon initial deployment. But if you are experiencing this, then I recommend again using the VirtualBox Manager to set the Snapshot Folder to a non-existent directory once the device is deployed. This can be done via Settings->General->Advanced for each device you wish to disable snapshotting.

Suspicously timed EC2 instance restart

Yes, I've heard all the stories about EC2 instances being unreliable and how you need to proactively prepare for that. I've also heard stories from others about how they have never had a problem, and their instances just run and run.
Today I had a strange thing happen. I've had an Linux instance running for a couple of months, as I've been preparing to launch an e-commerce site. I've been periodically taking snapshots. I have my images on S3. I have my code in a private github repo. All things considered, I've been doing a fairly good job of protecting myself against failure. Ironically, it was while I was doing even more in this regard today that I experienced something really strange.
Since I have these snapshots, I had assumed that the best thing to do if I needed to quickly spin up a new instance (whether due to a failed instance that wouldn't come back up, or if I just needed additional capacity) would be to take a snapshot and make a volume out of it, then make an image out of that volume, and then launch a new instance using that image.
For whatever reason, every time I've tried that lately, the new instance had a kernel panic during boot, so I decided to try a different approach. I right-clicked on my RUNNING INSTANCE, and chose "Create Image." That seemed like a reasonable shortcut. Then I went to that image and launched an instance.
At almost exactly the same time, my original instance rebooted. I didn't even see it happen. I only know it did from the system log. Is this just a wild coincidence? Or did I commit a silly mistake and accidentally screw up my instance?
Fortunately, I'm just getting this new thing off the ground, so the bit of downtime didn't kill me, and I was able to very quickly get things going again. But either I totally do not understand the "Create Image" feature from the instance list, or I got really unlucky today.
"Create image" takes the following actions:
Stop EC2 instance
Snapshot EBS volume
Start EC2 instance
Register EBS snapshot as an AMI
So, yes, this would look like a reboot because it is like a reboot.
Here's an article I wrote on the difference between stop/start and simple reboot: http://alestic.com/2011/09/ec2-reboot-stop-start
Your problem sounds a lot like my problem. After some searching this page helped me: http://www.raleche.com/node/138
"The problem turned out to be the kernel. Both when creating the AMI and the instance I selected default for the kernel image.
To resolve the problem, I recreated the AMI using the same kernel image as the original instance."

How VMWare Snapshot "Save" VM's state without copying all the VM files?

I was wondering, what kind of technique VMware Snapshots uses to assure that you will be able to return to a previous state without copying all the VM's disk?
It is basically a delta child disk. Operations are made it it while running off the snapshot. Makes it easy to revert.
link to explanation