On 05/31/2011 03:48 PM, Mike Snitzer wrote:
On Tue, May 31 2011 at 2:39pm -0400,
Anthony Liguori<anthony@xxxxxxxxxxxxx> wrote:
Are you referring to merging taking place which can change the definition
of IOPS as seen by guest?
No, with qcow2, it may take multiple real IOPs for what the guest
sees as an IOP.
That's really the main argument I'm making here. The only entity
that knows what a guest IOP corresponds to is QEMU. On the backend,
it may end up being a network request, multiple BIOs to physical
disks, file access, etc.
Couldn't QEMU give a hint to the kernel about the ratio of guest IOP to
real IOPs? Or is QEMU blind to the real IOPs that correspond to a guest
IOP?
Perhaps, but how does that work when the disk image is backed by NFS?
And even if you had a VFS level API, we can do things like libcurl based
block devices in QEMU. So unless you tried to do level 5 traffic
throttling which hopefully, you'll agree is total overkill, we're going
to need to have this functionality in QEMU no matter what.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
