I have a KVM machine that returns an error upon changing any hardware.
Other machines don't have the problem.
http://public.earthling_unbound.f-m.fm/screenshot/pvedaemon176xxerror.gif
pvedaemon unable to apply VM settings, command failed: /usr/sbin/qm set 101 --ide3
pvedaemon unable to set cdrom, command failed: /usr/sbin/qm cdrom 101 --ide3 local:iso/
This morning it was restored from a daily snapshot taken 3 days prior.
There was a disk on the machine being restored that wasn't present during the snapshot, so after the restore I followed the procedure outlined in this post to transfer it.
Immediately afterward I was able to sequentially delete & add IDE devices such that they were on the desired channels.
I've been running this machine all afternoon & have seen nothing to indicate that anything had gone wrong until now.
##### EDIT
I was looking for today's backup to restore when I saw that it wasn't there yet. Then I looked & saw a temp folder still present in the backup directory.
When I looked at the log there was nothing recent enough to see, so I looked at currently running processes & found vmtar still crunching away at the first machine for 8 1/2 hours.
It's likely working on the 500GB disk that got renamed earlier. Plus the VM's 100GB.
I have a NAS box with a bunch of IDE drives ready as an iSCSI target to store the 500GB disk. That's what I was trying to add when I discovered I couldn't.
Being that such a large disk will still be a part of that machine I wonder if it'll actually slow the process due to added latency.
Aside from removing compression, are there any options to improve the speed of backups?
I've yet to query "backup speed" or "best practices" in the forum, however expert feedback's always welcome.
Other machines don't have the problem.
http://public.earthling_unbound.f-m.fm/screenshot/pvedaemon176xxerror.gif
pvedaemon unable to apply VM settings, command failed: /usr/sbin/qm set 101 --ide3
pvedaemon unable to set cdrom, command failed: /usr/sbin/qm cdrom 101 --ide3 local:iso/
This morning it was restored from a daily snapshot taken 3 days prior.
There was a disk on the machine being restored that wasn't present during the snapshot, so after the restore I followed the procedure outlined in this post to transfer it.
Immediately afterward I was able to sequentially delete & add IDE devices such that they were on the desired channels.
I've been running this machine all afternoon & have seen nothing to indicate that anything had gone wrong until now.
##### EDIT
I was looking for today's backup to restore when I saw that it wasn't there yet. Then I looked & saw a temp folder still present in the backup directory.
When I looked at the log there was nothing recent enough to see, so I looked at currently running processes & found vmtar still crunching away at the first machine for 8 1/2 hours.
It's likely working on the 500GB disk that got renamed earlier. Plus the VM's 100GB.
I have a NAS box with a bunch of IDE drives ready as an iSCSI target to store the 500GB disk. That's what I was trying to add when I discovered I couldn't.
Being that such a large disk will still be a part of that machine I wonder if it'll actually slow the process due to added latency.
Aside from removing compression, are there any options to improve the speed of backups?
I've yet to query "backup speed" or "best practices" in the forum, however expert feedback's always welcome.
Last edited: