It would be great if we could find out from qemu that it was refusing to start because it couldn't restore from file, perhaps that's possible.

That would help with the error reporting, of course, but the creation of the machine shouldn't fail at all.

However, virt-manager could realize there is a managed save for the machine and offer reseting the machine to the default shutoff state.  I'll take it as a non-critical RFE.

In the meantime, I'll try to reproduce the issue, as it seems very common, and will see what we can do about the failing start of suspended domains.  Especially when libvirt-guests service handles them properly.

Can you tell me how to reproduce this bug?

The setps are not clear, can you tell me how to reproduce this bug?

(In reply to comment #7)
> The setps are not clear, can you tell me how to reproduce this bug?

I don't know exactly how to reproduce it.  All I know is that somehow the suspend date for a guest got corrupted during suspend or thereafter and I couldn't resume it and then I'd end up with the confusing error message noted.

One user reports http://johnpoelstra.com/resuming-corrupted-suspended-guests/#comment-2618 

"This same message occurs if one overallocates memory to the VM. I got this message and it took a while before I realized that the issue was not a suspended machine, but overallocation of memory!!"

Eric, you're looking into the libvirt and qemu changes that might be required to produce a more helpful message, so I'm handing this BZ over to you as well.

Reproduction should be easy.  Try these steps:

1. Create simple machine (any startable machine will do)
2. run 'virsh managedsave <machinename>'
3. edit '/var/lib/libvirt/qemu/save/<machinename.save>' in a manner that will cause the startup to fail (I tried changing the XML so that qemu has to allocate impossible amount of memory, 32768 GiB was enough)
4. try starting the machine

Let me know if that works for you and reproduces the error.  The error message might be different from 'Unable to read from monitor: Connection reset by peer'.  It depends on the way how you edit the file, I just described the easiest one.

I change the '/var/lib/libvirt/qemu/save/rhel.save', but the error message is not unhelpful.

[root@localhost ~]# uname -a
Linux localhost.localdomain 2.6.32-369.el6.x86_64 #1 SMP Thu Mar 28 21:49:55 EDT 2013 x86_64 x86_64 x86_64 GNU/Linux
[root@localhost ~]# rpm -qa qemu-kvm  virt-manager libvirt
virt-manager-0.9.0-18.el6.x86_64
libvirt-0.10.2-18.el6.x86_64
qemu-kvm-0.12.1.2-2.360.el6.x86_64

1. Create simple machine (my guest's name is rhel)
2. #virsh managedsave rhel
3. I edit the domain's name from 'rhel' to 'rhel.' in rhel.save file, and save the file
4. after that I can't start the vm , the error message tell me the domain name stuff.

---------------------------------------

Error restoring domain: operation failed: cannot restore domain 'rhel' uuid 27ace8b6-0afc-35a6-c73a-02f428f2aa08 from a file which belongs to domain 'rhel.' uuid 27ace8b6-0afc-35a6-c73a-02f428f2aa08

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 44, in cb_wrapper
    callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 65, in tmpcb
    callback(*args, **kwargs)
  File "/usr/share/virt-manager/virtManager/domain.py", line 1063, in startup
    self._backend.create()
  File "/usr/lib64/python2.6/site-packages/libvirt.py", line 678, in create
    if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
libvirtError: operation failed: cannot restore domain 'rhel' uuid 27ace8b6-0afc-35a6-c73a-02f428f2aa08 from a file which belongs to domain 'rhel.' uuid 27ace8b6-0afc-35a6-c73a-02f428f2aa08

---------------------------------------

Sorry, I can't give reproducer... I don't have a RHEL 6 machine any more.

I think it's actually a general problem--we need better information transfer between qemu and libvirt to indicate the cause of startup failures.  That's going to require quite a bit of coordination though.

I think this is how we triggered it using Virtual Machine Manager:

1. Shutdown/Save the guest
2. Remove virtual disk from the guest
3. Add a new virtual disk to the guest
4. Try to resume the guest

This led to the error message:

Error restoring domain: Unable to read from monitor: Connection reset by peer

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 44, in cb_wrapper
    callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 65, in tmpcb
    callback(*args, **kwargs)
  File "/usr/share/virt-manager/virtManager/domain.py", line 1063, in startup
    self._backend.create()
  File "/usr/lib64/python2.6/site-packages/libvirt.py", line 619, in create
    if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
libvirtError: Unable to read from monitor: Connection reset by peer

*** This bug has been marked as a duplicate of bug 765733 ***