<h1>Using qcow2 with NBD</h1>
<p>
- Filler - need to demonstrate:
+ <table style="border:1px solid black;">
+ <tr>
+ <th>XXX: better header...</th>
+ <th>qemu -> (raw) -> qemu-nbd -> (qcow2) -> image.qcow2</th>
+ <th>qemu -> (qcow2) -> qemu-nbd -> (raw) -> image.qcow2</th>
+ </tr>
+ <tr>
+ <td>Pro</td>
+ <td>
+ <ul>
+ <li>Matches existing use
+ <li>Server can start with thin qcow2, and grow it as needed
+ with guest activity
+ </ul>
+ </td>
+ <td>
+ <ul>
+ <li>Guest-visible size can be changed
+ <li>Backing files
+ <li>Dirty bitmap tracking
+ <li>Any other qcow2 features...
+ </ul>
+ </td>
+ </tr>
+ <tr>
+ <td>Con</td>
+ <td>
+ <ul>
+ <li>Guest size is fixed
+ <li>No access to qcow2 features from client
+ </ul>
+ </td>
+ <td>
+ <ul>
+ <li>Server file must be preallocated, or else guest hits ENOSPC
+ <li>Internal snapshots are unlikely to work
+ </ul>
+ </td>
+ </tr>
+ </table>
- <pre>
- qemu -> (raw) -> qemu-nbd -> (qcow2) -> image.qcow2
- qemu -> (qcow2) -> qemu-nbd -> (raw) -> image.qcow2
- </pre>
-
- maybe a table of pro/con for each
-
-<p>
- Exposing qcow2 over NBD is too risky without resize, forcing
- existing documentation to favor raw over NBD, even though this loses
- out on the other benefits of qcow2.
+ <p>Can we merge the best of both worlds, giving the client access to
+ all qcow2 features, but permitting resize of the underlying file on
+ the host?
</p>