Re: [libvirt] ZFS backend does fail if used on non top level pools

On 05/02/2018 03:36 AM, Christian Ehrhardt wrote: 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). So the source.name is probably wrong and should be def->name instead. When a volume is created in virStorageBackendZFSCreateVol the source.name and volume name are concatenated - so that seems right. This one is the "unknown" for me. What happens if you create Xzfs/images/vol1 (or your command below) without first creating Xzfs/images? What probably needs to happen, is the zfs backend needs to have a pool create added which does the zpool command and then the existing pool build command would check if def->name != def->source.name and then do the zfs create @def->source.name... Of course that also assumes that the def->name is STRPREFIX os the def->source.name. e.g., in this example the pool def->name is "Xzfs" and that's what starts the source.name of "Xzfs/image". I think instead of def->source.name here, def->name should be used. I would think def->source.name would *only* be used in conjunction with Storage Pool "Volume" API's while def->name would be used for anything in Storage Pool as a whole API's. I don't have a zfs pool to play with, but if someone proposes patches I'll look. I think there's a few hints above. Looks like Roman Bogorodskiy was the original author and Richard Laager has also made other improvements. John