12:38 a.m.
On Thu, May 19, 2011 at 11:24 PM, Eric Blake <eblake(a)redhat.com> wrote:
On 05/19/2011 04:09 PM, Stefan Hajnoczi wrote:
>> In case we need to refine later, we can still provide a larger set of
>> accepted values for that attribute, assuming people really want to
>> make more distinctive tuning,
>
> Inventing a different name makes life harder for everyone. There is a
> need for a generic API/notation that covers all virtualization
> software but this is a hypervisor-specific performance tunable that
> does not benefit from abstraction.
That's true if we narrow-mindedly think that qemu will be the _only_
hypervisor that will ever use this feature. But libvirt has the stated
goal of accommodating multiple hypervisors, so we'd rather go with the
generic name even if it requires more mapping.
That approach is an extreme approach, I'm not suggesting to make
everything hypervisor-specific, I'm asking for a practical middle
ground - abstract what is common, leave what is not.
There are many common concepts: how much RAM should the VM have, what
CPU topology, network cards, storage devices. Those should be
abstracted because they are genuinely common concepts. However, for
hypervisor-specific features inventing names does no good. The
feature is not relevant on other hypervisors and abstracting it
removes its semantics. It becomes purely an exercise in obfuscation.
When I browse the Python documentation many modules are
platform-independent and can be used everywhere. Some functions or
modules are specifically marked as platform-dependent (and the version
they were introduced in):
"os.initgroups(username, gid)
Call the system initgroups() to initialize the group access list with
all of the groups of which the specified username is a member, plus
the specified group id.
Availability: Unix.
New in version 2.7."
Doing the same in libvirt allows common concepts to be abstracted
while exposing unique ones in a clearly documented way.
> When I ask a user to try disabling ioeventfd I need to first
search
> through libvirt documentation and/or source code to reverse-engineer
> this artificial mapping. This creates an extra source of errors for
> people who are trying to configure or troubleshoot their systems. The
> "I know what the hypervisor-specific setting is but have no idea how
> to express it in libvirt domain XML" problem is really common and
> creates a gap between the hypervisor and libvirt communities.
Yes, good documentation that mentions the specific qemu option it maps
to would be helpful.
Also, libvirt has the domxml-from-native command, and if we do this
correctly, then you should be able to pass an arbitrary qemu command
line to libvirt, and ask what the corresponding xml would be. That
would make your reverse mapping less difficult.
Thanks for mentioning this command, I'll try it next time.
>
> The next time an optimization is added to QEMU you'll have to pick a
> new name, "asyncio" (already overloaded terminology today) won't be
> available anymore. We're going to end up with increasingly contrived
> or off-base naming.
Then please help us, by suggesting a generic name more suited to this
particular qemu tuning, but which can still be used for other
hypervisors if they can also tune the same semantics.
As I've said, inventing generic names only serves to confuse when the
concept is hypervisor-specific and not a common feature.
>
> Regarding semantics:
>
> Ioeventfd decouples vcpu execution from I/O emulation, allowing the VM
> to execute guest code while a separate thread handles I/O. This
> results in reduced steal time and lowers spinlock contention inside
> the guest. Typically guests that are experiencing high system cpu
> utilization during I/O will benefit from ioeventfd. On an
> overcommitted host it could increase guest I/O latency though. The
> ioeventfd option is currently only supported on virtio-blk (default:
> on) and virtio-net (default: off) devices.
>
> Please call it ioeventfd. Also, it can always be toggled using the
> <qemu:commandline> tag if you don't want to expose it natively in
> domain XML.
However, use of <qemu:commandline> results in an unsupported
configuration; we need to expose it natively in domain XML under some
name or another.
We already have the XML attribute io="threads|native" in the same
<driver> element, for selecting whether to use the aio flag for a given
disk driver, so this would not be the first case of selecting a
different name in the XML.
Just because it has been done before doesn't mean it is a good idea.
Stefan