virtualization <a href="#Functions">functions</a>. Depending upon the
driver being used, calls will be routed through the remote driver to
the libvirtd daemon. The daemon will reference the connection specific
- driver in order to retreive the requested information and then pass
+ driver in order to retrieve the requested information and then pass
back status and/or data through the connection back to the application.
The application can then decide what to do with that data, such as
display, write log data, etc. <a href="migration.html">Migration</a>
... note the process id from the output
# gdb /usr/sbin/libvirtd
.... some information about gdb and loading debug data
-(gdb) attach $the_damon_process_id
+(gdb) attach $the_daemon_process_id
....
(gdb) thread apply all bt
.... information to attach to the bug
<p>
If the container does not respond to the graceful shutdown
-request, it can be forceably stopped using the <code>virsh destroy</code>
+request, it can be forcibly stopped using the <code>virsh destroy</code>
</p>
<pre>
<p><a href="http://www.dmtf.org/standards/cim/cim_schema_v2230/CIM_Network.pdf">http://www.dmtf.org/standards/cim/cim_schema_v2230/CIM_Network.pdf</a></p>
<p>The filters are managed in libvirt as a top level, standalone object.
This allows the filters to then be referenced by any libvirt object
- that requires their functionality, instead tieing them only to use
+ that requires their functionality, instead tying them only to use
by guest NICs. In the current implementation, filters can be associated
with individual guest NICs via the libvirt domain XML format. In the
future we might allow filters to be associated with the virtual network
to update them. This ensures the guests have their iptables/ebtables
rules recreated.
</p>
- <p>To associate the clean-trafffic filter with a guest, edit the
+ <p>To associate the clean-traffic filter with a guest, edit the
guest XML config and change the <code><interface></code> element
to include a <code><filterref></code> and also specify the
whitelisted <code><ip address/></code> the guest is allowed to
<p>
The main libvirt event loop thread is responsible for performing all
- socket I/O. It will read incoming packets from clients and willl
+ socket I/O. It will read incoming packets from clients and will
transmit outgoing packets to clients. It will handle the I/O to/from
streams associated with client API calls. When doing client I/O it
will also pass the data through any applicable encryption layer
<td> libssh2 </td>
<td>
A comma separated list of authentication methods to use. Default (is
- "agent,privkey,keyboard-interactive". The order of the methods is perserved.
+ "agent,privkey,keyboard-interactive". The order of the methods is preserved.
Some methods may require additional parameters.
</td>
</tr>
</target>
</volume></pre>
- <h3>Example disk attachement</h3>
+ <h3>Example disk attachment</h3>
<p>RBD images can be attached to Qemu guests when Qemu is built
with RBD support. Information about attaching a RBD image to a
guest can be found