<h1>Using qcow2 with NBD</h1>
<p>
- Filler - need to demonstrate:
+ <table id="border">
+ <tr>
+ <th style="width:8%;"></th>
+ <th><img src="8000-raw-over-nbd.png"/></th>
+ <th><img src="8000-qcow2-over-nbd.png"/></th>
+ </tr>
+ <tr>
+ <td style="text-align:center;">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 style="text-align:center;">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>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>
-<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 class="attribution">
+ Clipart of computer <a href="http://clipart-library.com/clipart/76irEkBcK.htm">http://clipart-library.com/clipart/76irEkBcK.htm</a>
</p>
git.annexia.org / libguestfs-talks.git / blobdiff