Quoting Alvin (i...@alvin.be): > Unfortunately, this shows up in both host and guests. > > I haven't tried to use qemu-img on a snapshot, but I will. I fear it > will not make much difference. Just having snapshots (without accessing > them) is enough to bring the system down on moments with heavy I/O. > > Sometime this week, I will warn the users of their impending doom and > try out whether it makes a difference.
I assume you have very fast underlying storage and that's the trigger. Rather than running qemu-img under 'nice', I wonder whether you would be better off running qemu-img in a cgroup with tighter controls over its blkio. I've not experimented with this myself, but http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/cgroups/blkio-controller.txt;h=465351d4cf853e8a308c9c84abef789b3dcfa42c;hb=HEAD should give some good info. I also must point out that the only storage failures I've seen myself (roughly a year ago) were due to ext4 itself. I since switched to xfs for all root and data partitions and have not seen the like since. Unfortunately that's likely not a viable option for you as you have users already depending on the system (plus 2.6.38 is rumored to bring its own xfs instabilities, though I've not seen those here). However if it were possible, I'd highly recommending testing with xfs. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to qemu-kvm in Ubuntu. https://bugs.launchpad.net/bugs/712392 Title: qemu-img convert blocks other tasks -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
