On 6/16/11, Gordon Messmer wrote:
I think you were misinformed, or misled.
That wouldn't be new for me as far as system administration is concerned :D
LVM should not present any
noticeable overhead on the host. Using "raw" files to back VMs presents
a significant overhead to guests; the host performs all IO through its
filesystem. Using "qcow2" files presents even more overhead (probably
the most of any configuration) since there are complexities to the qcow2
file itself in addition to the host's filesystem.
I think you were misinformed, or misled.
That wouldn't be new for me as far as system administration is concerned :D
LVM should not present any
noticeable overhead on the host. Using "raw" files to back VMs presents
a significant overhead to guests; the host performs all IO through its
filesystem. Using "qcow2" files presents even more overhead (probably
the most of any configuration) since there are complexities to the qcow2
file itself in addition to the host's filesystem.
that qcow2 would be slower for the added functionality. However there
was some site I found that showed that KVM with virtio, turning off
host caching (or specifying write-back instead of the default
write-through) on the file and doing preallocation on qcow2 files will
make qcow2 as fast as raw.
It shouldn't be significantly harder to copy the contents of a partition
or LV. The block device is a file. You can read its contents to copy
them just as easily as any other file.
Although the combination of ionice and atime seemed to have stoppedor LV. The block device is a file. You can read its contents to copy
them just as easily as any other file.
things from going through the roof, I'll probably still try to convert
one of them to LVM and see if that improves things even further.
