You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi,
in the pool provider, virsh pool-build is always called after virsh pool-define. But in some cases, you don't want to build the pool. For example, when you define a LVM group pool, the LVM group in most situation already exists on the system, so, pool-build raise an error.
The error is caught and simply noticed by the provider, so it works btw, but it can be very dangerous to call it : who know the behavior of libvirt in the future, and so the risk of losing data.
May be it can be a good idea to add a "build" (or nobuild) boolean parameter to the pool type ? or at least to add the "--no-overwrite" flag to pool-build to be sure libvirt will never try something .... dangerous :)
What do you think about ?
Anthony.
The text was updated successfully, but these errors were encountered:
I do not use this functionality currently. But adding a build parameter seems to be a good idea
as far as I understand the problem.
I would be happy to merge a pull request.
Hi,
in the pool provider,
virsh pool-build
is always called aftervirsh pool-define
. But in some cases, you don't want to build the pool. For example, when you define a LVM group pool, the LVM group in most situation already exists on the system, so, pool-build raise an error.The error is caught and simply noticed by the provider, so it works btw, but it can be very dangerous to call it : who know the behavior of libvirt in the future, and so the risk of losing data.
May be it can be a good idea to add a "build" (or nobuild) boolean parameter to the pool type ? or at least to add the "--no-overwrite" flag to pool-build to be sure libvirt will never try something .... dangerous :)
What do you think about ?
Anthony.
The text was updated successfully, but these errors were encountered: