I am taking a snapshot of a virtual machine using VSphere. My problem is that it is taking a very long time and I have some things I need to do on that virtual machine. My question is: Is it safe for me to use the VM while the snapshot is being created? Why or why not?
("Safe" as in will the snapshot be ruined? Will the snapshot be taken at some intermediate state instead of the time that I originally initiated the snapshot?)
Taking a snapshot is usually a fast operation where writes are redirected to other files (in order to revert them). If the operation takes a long time it might be caused of including saving the vm:s memory to disk as well. If this is not the case maybe you have an issue where taking the snapshot isn't working.
Under normal situations there shouldn't be any problem working of changing data inside the vm at this point.
Related
Are there any differences i.e. advantages/disadvantages to saving the machine state of a VirtualBox appliance while it is paused?
I used to save the machine state of appliances without them being paused (Close -> Save the Machine State), but have just found out that if I do this after pausing the appliance that it seems to have the same effect. In fact, when I start the appliance again, it is automatically unpaused, which is interesting.
Does anyone know if pausing an appliance affects saving the machine state in any way?
Thanks in advance for your reply.
actually that's some of the perks of working with Virtual Machines, not to mention the security and consistence you get if you work with them. Saving the state machine and other ways does not affect the performance of them, you even can do things like:
You can move the copy to another installation and resume your
execution.
Do snapshots of the Virtual Machines. Which is something like a "photo" of that moment of the Virtual Machine.
Cloning it to run another copy on the host.
Live migration and this does not affect the processes of the user.
If you want to learn more, I recommend you this book: http://iips.icci.edu.iq/images/exam/Abraham-Silberschatz-Operating-System-Concepts---9th2012.12.pdf
In redis logs, a line related to background saves appears often, e.g.:
[11465] 06 Mar 08:10:11.292 * RDB: 541 MB of memory used by copy-on-write
Can anyone clarify what this line precisely means?
When redis wants to save a snapshot, it does that by forking itself first and then the forked process saves the dataset, not disturbed by having to serve requests, etc.
Since you have two processes now, it could mean using twice as much RAM, right? But no, the operating systems actually optimize this scenario by having the new process refer memory pages of the old process.
Interesting thing happens when original server's memory changes after the fork (due to you issuing update commands or something). The forked process has to maintain whatever memory state it got when forked, so the system, before changing a shared page, copies the page to the forked process (so that it's no longer shared) and then changes original process' page. This is called "copy-on-write".
In your case, this roughly means that during time it needed for saving a snapshot, you changed 541MB of data.
Being relatively new to GCE, but not to other virtualization tools like VmWare or VirtuaBox, I'm not able to find in GCE a concrete way to get a full snapshot of a live machine.
I'm guessing it's my fault or poor knowledge, but really GCE doesn't saves the "system state", or else dumps memory to snapshot?
I'd found many scripts and examples on how to flush buffers to disks before I create the snapshot, but no way to obtain a complete state of the machine, including what the machine itself is running at THAT point.
Let me say that, if this is correct, the GCE snapshot IS NOT a snapshot.
Thanks in advance for your help.
That's a VM image, not a snapshot, and it does not include the contents of RAM or the processor state. A snapshot is a point-in-time copy of a persistent disk.
[link] (http://vcloud.vmware.com/uk/using-vcloud-air/tutorials/working-with-snapshots)
Here's an example of a cloud platform saving true snapshots, portraits of a specific second of a working machine.
Let me add a thought:
I don't know if VCloud is considering a particular state, gains privileged access to disks for a limited time, avoiding contingency, or else does a temporary duplication of the working disk in another volume.
I'm still reading around, trying to get INTO the problem.
BUT... it dumps memory to snapshot.
This is the point, and I'm wondering why this seems to be not possible in GCE.
I'm starting to assess our company using RavenDB for storing some stuff that doesn't really belong in a relational database (we're traditionally a SQL Server shop). I installed RavenDB locally on my machine, created a database, added a document. Nice!
Being a DBA, I decided to see how backups/restores work. I backed up my database, deleted it, then restored it from the backup. After refreshing my admin screen, I saw my database. I clicked on it, and got a message that the database doesn't exist.
After a couple hours, I tried again. Still doesn't exist. A full day later, I walk into work, and try again. This time the database works. I've had similar situations with updating documents. The update seems to take anywhere between 1 second - several hours to show an update...
Is this normal for RavenDB?? Am I completely misconfigured?? I run SQL Server on my local machine and it's lightning-fast, so I can't imagine updating a single document could take that long. As-is, I can't imagine recommending we use RavenDB for anything.
Are you querying using indexes or getting documents by ID? Documents should be updated immediately (ACID). If indexes are slow to update (check their status using RavenDB Studio), it could be a configuration problem or something external like an anti-virus software can cause them to update slowly.
Apparently, at least for the document-update latency, the default for caching in queries is enabled, so I was getting cached results.
Jeffery,
No, that isn't normal by a long short. You should be able to immediately see what was changed.
Note that certain AV products will interfere with the HTTP pipeline and can affect RavenDB's usage. The studio will also auto update things only every 5 seconds (to reduce UI jitter), but that is about it.
Restoring a database (from the same machine), should take only as long as it take to copy the files (pure I/O bound operation).
If this is from another machine using a different version of Windows, we might need to run a check on the file, which can take a bit of time, but that doesn't sound like your scenario
I've been using 3 identical VMs on Azure for a month or more without problem.
Today I couldn't Remote Desktop to one of them, and restarted it from the Azure Portal. That took a long time. It eventually came back up, and the Event log has numerous entries such as:
"The IO operation at logical block address 70 for Disk 0 ..... was retried"
"Windows cannot access the file C:\windows\Microsoft.Net\v4.0.30319\clrjit.dll for one of the following reasons, network, disk etc.
There are lots of errors like this. To me they seem symptomatic that the underlying disk system is having serious problems. Given the VHD is stored in a triple replicated Azure blob, I would have thought there was some immunity to this kind of thing?
Many hours later it's still doing the same thing. It works fine for a few hours, then slows to a crawl with the Event log containing lots of disk problems. I can upload screen shots of the event log if people are interested.
This is a pretty vanilla VM, I'm only using the one OS disk it came with.
The other two identical VMs in the same region are fine.
Just wondering if anybody has seen this before with Azure VMs and how to safeguard against it, or recover from it.
Thanks.
Thank you for providing all the details and we apologize for the inconvenience. We have investigated the failures and determined that they were caused by a platform issue. Your virtual machine’s disk does not have any problems and therefore you should be able to continue using it as is.