<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>> This one is the "unknown" for me. What happens if you
create<br>
> Xzfs/images/vol1 (or your command below) without first
creating Xzfs/images?</p>
<p>Answer: it fails, unless you give the '-p' flag.</p>
<p><tt> -p</tt><tt><br>
</tt><tt><br>
</tt><tt> Creates all the non-existing parent
datasets. Datasets created in this manner</tt><tt><br>
</tt><tt> are automatically mounted according to
the mountpoint property inherited from</tt><tt><br>
</tt><tt> their parent. Any property specified on
the command line using the -o option</tt><tt><br>
</tt><tt> is ignored. If the target filesystem
already exists, the operation completes</tt><tt><br>
</tt><tt> successfully.</tt></p>
<p>Example: given an existing zfs pool called "zfs":<br>
</p>
<p><tt># zfs create zfs/foo/bar</tt><tt><br>
</tt><tt>cannot create 'zfs/foo/bar': parent does not exist</tt><tt><br>
</tt><tt># zfs create -p zfs/foo/bar</tt><tt><br>
</tt><tt># zfs list zfs/foo</tt><tt><br>
</tt><tt>NAME USED AVAIL REFER MOUNTPOINT</tt><tt><br>
</tt><tt>zfs/foo 192K 23.5G 96K /zfs/foo</tt><tt><br>
</tt><tt># zfs list -r zfs/foo</tt><tt><br>
</tt><tt>NAME USED AVAIL REFER MOUNTPOINT</tt><tt><br>
</tt><tt>zfs/foo 192K 23.5G 96K /zfs/foo</tt><tt><br>
</tt><tt>zfs/foo/bar 96K 23.5G 96K /zfs/foo/bar</tt></p>
However, I don't see this as a problem for libvirt. The parent
should already exist when you define the pool, and I expect libvirt
will only create immediate children.<br>
<br>
<pre style="color: rgb(0, 0, 0); font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-style: initial; text-decoration-color: initial;">> If one digs into the virStorageBackendZFSBuildPool they will see libvirt
> pool create/build processing would "zpool create $name $path[0...n]"
> where $name is the "source.name" (in your case Xzfs/images) and
> $path[0...n] would be the various paths (in your case tmp/Xzfs)
</pre>
<p>Just to be clear, creating a zpool ("zpool create") is different
to creating a zfs dataset ("zfs create").<br>
</p>
<p>By analogy to LVM: a zpool is like a volume group, and a zfs
dataset/zvol is like a logical volume.</p>
<p>A zpool (or VG) is created from a collection of block devices -
or something which looks like a block device, e.g. a partition or
a loopback-mounted file. Those are $path[0...n] in the above, and
would be called "physical volumes" in LVM.<br>
</p>
"zfs create" then creates a dataset (filesystem) or zvol (block
device) which draws space out of the zpool. The analogous operation
in LVM is "lvcreate", although it will only give you a block device
- it's up to you to make a filesystem within it.<br>
<br>
In summary:<br>
<br>
zpool create ==> vgcreate (*)<br>
zfs create -V ==> lvcreate<br>
<br>
(*) LVM also requires you to label the block devices with "pvcreate"
before you can add them to a volume group. zpool create doesn't
require this.<br>
<br>
From my point of view, as a libvirt user: I *could* dedicate an
entire zpool to libvirt, but I don't want to. It would mean libvirt
has full ownership of that set of physical disks, and I may want to
use the space for other things as well.<br>
<br>
What I want to do is to allow libvirt to use an existing zpool, with
a parent dataset which it can allocate underneath, like this:<br>
<br>
<span style="color: rgb(51, 51, 51); font-family: monospace;
font-size: 12px; font-style: normal; font-variant-ligatures:
normal; font-variant-caps: normal; font-weight: 400;
letter-spacing: normal; orphans: 2; text-align: left; text-indent:
0px; text-transform: none; white-space: normal; widows: 2;
word-spacing: 0px; -webkit-text-stroke-width: 0px;
background-color: rgb(255, 255, 255); text-decoration-style:
initial; text-decoration-color: initial; display: inline
!important; float: none;"><span style="color: rgb(51, 51, 51);
font-family: monospace; font-size: 12px; font-style: normal;
font-variant-ligatures: normal; font-variant-caps: normal;
font-weight: 400; letter-spacing: normal; orphans: 2;
text-align: left; text-indent: 0px; text-transform: none;
white-space: normal; widows: 2; word-spacing: 0px;
-webkit-text-stroke-width: 0px; background-color: rgb(255, 255,
255); text-decoration-style: initial; text-decoration-color:
initial; display: inline !important; float: none;">zfs create
zfs/libvirt<br>
</span>virsh pool-define-as --name zfs --source-name zfs/libvirt
--type zfs</span><br>
<br>
(instead of using pool-create/pool-build). This not only makes it
clear which datasets belong to libvirt, but allows me to do things
like storage accounting at the parent dataset level.<br>
<p>And actually, this almost works. It's just the pool refresh which
fails, because it tries to treat "zfs/images" as if it were a
zpool. Stripping off everything up to the first slash for "zpool
get" would fix this.</p>
<p>Arguably this uncovers a couple of other related issues to do
with error handling:</p>
- to the end user, "virsh pool-refresh" silently appears to work
(unless you dig down deep into logs), even though the underlying
"zpool get" returns with an error
<p>- by this stage, pool-refresh has already destroyed all existing
libvirt volumes which were previously in the pool</p>
<p>Regards,</p>
<p>Brian.<br>
</p>
</body>
</html>