Found with the codespell utility.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
The host CPU architecture and features.
Note that, while this element contains a ``topology`` sub-element,
- the information contained therein is farily high-level and likely
+ the information contained therein is fairly high-level and likely
not very useful when it comes to optimizing guest vCPU placement.
Look into the ``topology`` *element*, described below, for more
detailed information.
automatically distributed among the configured iothreads.
Optionally the ``iothread`` element can have multiple ``queue``
- subelements with mandatory ``id`` atribute specifying that the iothread
+ subelements with mandatory ``id`` attribute specifying that the iothread
should be used to handle given virt queue. If queue mapping is present
the ``queues`` attribute of ``driver`` must be configured and all
configured virt queues must be included in the mapping. The
This element does not work with the ``passthrough`` backend.
- When specified, it is the user's responsability to prevent files from being
+ When specified, it is the user's responsibility to prevent files from being
used by multiple VMs or emulators (swtpm will also use advisory locking). If
not specified, the storage configuration is left to libvirt discretion.
https://developer.gnome.org/glib/stable/glib-Arrays.html
- Instead of using plain C arrays, it is preferrable to use one of
+ Instead of using plain C arrays, it is preferable to use one of
the GLib types, ``GArray``, ``GPtrArray`` or ``GByteArray``.
These all use a struct to track the array memory and size
together and efficiently resize.