Search results

What exactly are you missing? The first backup got cancelled by some external circumstance, the other backup is still "running". I think when it eventually finishes, the final lines are just the normal ones that appear after every backup.

I have this problem with a backup one one VM: the backup starts "ok" (not as fast as it could, but reasonable speed) but at some point slows down to almost no progress. Here are two logs: As you can see, there are sometimes "gaps" like in Log 1 between 59% and 60% it took more than 6000...

I have the same problem. Some processes have etime, but some do not. An example: # ps -e -o user,pid,start,etime,command USER PID STARTED ELAPSED COMMAND root 1 Apr 04 3-19:49:38 /lib/systemd/systemd --system --deserialize 15 root 48 Apr 04 3-19:49:36...

Ok thanks. I have disabled iothread and the backup seems to run fine. I now found out that someone else had that problem before me: http://forum.proxmox.com/threads/22903-Proxmox-4-0-beta-vm-with-iothread-on-virtio-disk-causes-vm-crash-during-vzdump Thanks again, Stefan

Well, I did not assume that every change that was made in 1.7 would also be made in 2.4+ - software development often doesn't work that way. But I'm happy to hear that you are sure that this particular fix is also in the source code for the current qemu branch and I'll take your word for it...

Would it be possible to port this fix to Proxmox 4.0? I'm having the same issue there. Setting the Backup Mode to "Suspend" or "Stop" works fine. Regards, Stefan

pve-kernel-3.19.8-1-pve 3.19.8-3

No, it complains exactly about rdtscp when I use the Opteron_Gx models. Thanks, Stefan

I do have the same problem with AMD FX-6300 and FX-9590 CPUs. When I copy the command and remove the enforce option, the VM starts up fine. Maybe it's worth putting a checkbox there to optionally select enforce (if one really needs to enforce this CPU type)? But at the very least for "host"...