[PVE-User] pvestatd: exclude ZFS pool from being read

[René Mayrhofer]

Update: I have now moved (via backup/restore) the VMs from the ZFS-based
pool to the LVM-based one on the SSD. Additionally, I have even removed
the ZFS pool as a storage in the PVE web interface. Nonetheless, when
pvestatd is running, the disks are prevented from spinning down. Is this
intentional? Why is pvestatd even touching disks that are not in any way
registered with PVE itself (ZFS pool created manually) and actively
reading from them?

I have yet to debug pvestatd itself to see where that behavior comes
from, but I am hesitant to change it as long as I don't understand the
intended behavior.

best regards,
Rene

Am 2016-07-19 um 21:36 schrieb René Mayrhofer:
> Am 2016-07-19 um 19:25 schrieb Dietmar Maurer:
>>> Unfortunately, I didn't find any documentation on how to configure
>>> pvestatd (manual pages, first web searches, etc.). How can I tell
>>> pvestatd to exclude that ZFS pool from its regular scans or to only read
>>> meta-data (e.g. zfs list or zpool iostat -v will return free space on
>>> the pool without touching the disks)? I
>> You cannot do that - this feature is simply not implemented.
> Why does pvestatd even read directly from the disks (or the single VM
> image I configured on that pool)? Does it need more than disk usage from
> the storage pools? That could be acquired from in-memory meta data only,
> I strongly assume. If I misunderstand the point of pvestatd, then maybe
> I need to setup my storage pools differently to make Proxmox better
> usable for a home / SME setting? Is pvestatd supposed not to read from
> the pool when there is no VM configured on it?
>
> Just for reference, the custom server I am testing now consumes around
> 16-25W in idle mode with discs off and around 40-45 with the platters
> spinning. That difference (also quite noticeable in temperature and
> therefore fan noise) makes it highly interesting to spin down the discs
> for as long as possible. When the setup is working, We plan to publish
> that on the institute's web page as a howto/recommended configuration
> for energy-efficient home / SME virtualization (looking at future smart
> homes here).
>
> Thanks,
> Rene
>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.proxmox.com/pipermail/pve-user/attachments/20160721/c6c71473/attachment.sig>