Re: [libvirt] [PATCH 0/3] add option to keep nvram file on undefine

On 27.05.2016 10:05, Nikolay Shirokovskiy wrote: >   There is already a patch [1] on this topic with a different approach - keep > nvram file by default. There is also some discussion there. To sum up keeping > nvram on undefine could be useful in some usecases so there should be an option > to do it. On the other hand there is a danger of leaving domain assets after > its undefine and unsing them unintentionally on defining domain with the same > name. >  >   AFAIU keeping nvram by default was motivated by domain disks behaviour. > I think there is a difference as libvirt never create disks for domain as > opposed to nvram and managed save and without disks domain will not start so > user is quite aware of disks files. On the other hand one can start using nvram > file solely putting <nvram> in config and managed save is created on daemon > shutdown. So user is much less aware of nvram and managed save existence. Thus > one can easily mess up by unaware define $name/using/undefine/define $name again > usecase. Thus I vote for keeping said assets only if it is specified explicitly > so user knows what he is doing. >  >   Adding option to undefine is best solution I come up with. The other options > are add checks on define or start and both are impossible. Such a check should > be done without any extra flags for it to be useful but this way we break > existing users. >  >   As this a proof of concept this series does not add extra flag for managed save. >  > [1] https://www.redhat.com/archives/libvir-list/2015-February/msg00915.html >  > Nikolay Shirokovskiy (3): >   api: add VIR_DOMAIN_UNDEFINE_KEEP_NVRAM flag >   qemu: add VIR_DOMAIN_UNDEFINE_KEEP_NVRAM support >   virsh: add --keep-nvram option to undefine command >  >  include/libvirt/libvirt-domain.h |  1 + >  src/qemu/qemu_driver.c           | 26 +++++++++++++++++--------- >  tools/virsh-domain.c             |  8 ++++++++ >  tools/virsh.pod                  |  6 +++--- >  4 files changed, 29 insertions(+), 12 deletions(-)   The patches look good to me (although the commit messages could be a little more verbose, e.g. explain why we need to have X and !X flags at the same time). I've went trough the discussion you linked and even though I usually agree with Dan, this time I think we must not change the behaviour of undefine and thus need a special flag for keeping NVRAM.   ACK, but we might want to give him (or anybody else) chance to chime in, so please postpone the push for a while. Thanks!