1

I had to reboot the host server but I did not want to stop one of my running VMs there. So what I did:

virsh save VM to save the vm state and restore it later with: virsh restore VM. Every thing worked fine, so I could access my vm again. In the meanwhile I erased the file created when you run virsh save since I thought (and I still think) that once the vm is restored is not needed anymore.

After one hour my VM froze and I did not manage to boot it again. What is the right way to save and restore Running VMs?

2
  • You haven't asked a question. Have you looked i your logs ?
    – user9517
    Nov 23 '17 at 19:21
  • Yes I did, and nothing. The only way I found to fix the problem is copying the entire Vm hard disk and creating a new VM. Then it booted.
    – edgarstack
    Nov 24 '17 at 13:56
1

So with your question, "What is the right way to save and restore Running VMs?" you pretty much nailed it on the head. Saving with virsh save VM and restoring with virsh restore VM will do what you wanted it to do--that is save memory to disk and then stop the VM (see the first section of this link).

When your VM froze, I believe you would have been able to restore if you had not deleted the state file (depending on the root cause of the VM failure in the first place).

I generally do not save memory to state files because my use case runs persistent, stateless services that do not depend on memory. If I need to shut down I usually just run virsh destroy VM and then start it as necessary. But, this all depends on your own use case.

You may want to also look into backing up your VM with snapshots, if you are leery of losing your machine again. Something like:

virsh snapshot-create-as --domain {VM-NAME} --name "{SNAPSHOT-NAME}"

See NixCraft for more details.


In any case, for getting your VM running after it froze you could have simply undefined the broken VM and re-attached the originally existing image from it to a new VM by updating the newly created VM's XML configuration document. First, tear down the original VM:

:~$ virsh destroy OriginalVM
:~$ virsh undefine OriginalVM

After that build the new VM, stop it and access the config:

:~$ virt-install --virt-type kvm --name NewVM --memory 4096 --disk size=1 --vcpus 4 --location /yadda/yadda.iso --network bridge=br0 --os-type=linux --so-on-and-so-forth
:~$ virsh destroy NewVM
:~$ virsh edit NewVM

Then, when editing the XML file search for "disk" by typing /disk and update the path for the source file:

 <disk type='file' device='disk'>
  <driver name='qemu' type='raw'/>
  <source file='/update_to/path_of/OriginalVM.img'/>

After saving and exiting (:w, :q or simply :x) you should be able to execute a virsh start NewVM and then access the new VM running your image via VNC, console, or ssh.

You could also try to clone your VM, though I have not tried this myself:

virt-clone --connect=qemu:///system -o srchost -n newhost -f /path/to/newhost.qcow2
2
  • Thanks for this very detailed and informative answer, can the virt-clone be used to migrate a machine to a new server?
    – edgarstack
    Nov 28 '17 at 12:02
  • You probably could do that, but it would take way more steps then you would want to do since it would require cloning, then still moving that clone in one fashion or another afterwards. I think what you would want is virsh migration. See this link: access.redhat.com/documentation/en-us/red_hat_enterprise_linux/… Nov 30 '17 at 5:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.