[SOLVED] pvesm remove local doesn't work, instead it re-enables it

[LiSergey]

I have installed PVE 7.2-1 from iso, and had some minor experiments with CentOS7 in LXC, which I've learned can't really work inside modern host system. It can't be a reason for crippling host system I think.

I noticed unconvenient storage layout, and decided move storage local to /rpool/data.
For that I've edited /etc/pve/storage.cfg and in GUI I've discovered the very disturbing unconsistency with pve/storage.cfg. GUI had local storage defined as dir /var/lib/vz.

Okay, I thought of some silent fool-proof feature to prevent unstarting VM due to absent hard drives, so I've removed from VMs all references to local storage and repeated my tweak. It didn't work either.

I disabled local in GUI, than issued pvesm remove local and it complained nothing about. Like it get it done. But after pvesm status I learned that not even it didn't work, it instead re-enabled that storage which I had deliberately disabled before removal.

If it is a kind of a fool-proof feature, than I expect verbosity and explanation why it is a dangerous move. And option to override if I understand what I'm doing and for what.

UPD.
I think I've did this trick (or tweak) several times in previous generation of PVE before, and it worked fine. I've deliberately repeated the same steps in an old production PVE-6.4-14/15e2bf61 and it reenabled disabled local storage, so I've probably did this trick with other storages, not the local one.
Anyway, that silent reenabling is unpredictable and in my taste is bad. If there are solid kill-proof reasons to keep alive local storage, than at least would be great to hear about that. As from output of pvesm remove local as in GUI.

 

[fiona]

Hi,
yes, the local storage is special and will be re-created, I think for historical reasons. What you can do is set the content type for the storage to none and/or disable the storage.

 

[fabian]

yes, local is used in some places as implicit fallback if no storage is given, so it will always be included in the parsed config even if missing from the actual config file. if you don't want to use it, disable it but leave it in the config.

 

[LiSergey]

yes, local is used in some places as implicit fallback if no storage is given, so it will always be included in the parsed config even if missing from the actual config file. if you don't want to use it, disable it but leave it in the config.

Thank you for clarification.

I'd love some verbosity on the command, kind of "can't really remove it, it is necessary. but you may leave it disabled in peace, though"
And a descriptory comment in /etc/pve/storage.cfg to give a hint to leave it alone.

 

[LiSergey]

Hi,
yes, the local storage is special and will be re-created, I think for historical reasons. What you can do is set the content type for the storage to none and/or disable the storage.

Yes, I guessed the same way to solve it. My point is more about style of unpredictability. Nobody presumably likes when software does not what is expected AND without any explanations or messages to consider. Kinda ignoring a person behind keybord, isn't it?

 

[fabian]

yeah, maybe an attempt to remove it via the API/pvesm could return a nice special error message!

 

[RolandK]

i have been pointed here from my ticket at https://bugzilla.proxmox.com/show_bug.cgi?id=4365

i think it's it's a little bit weird, that you can delete "local" datastore in webgui and it's getting deleted in storage.cfg whereas it's been still shown in webgui as an active datastore and it's being shown storage menu entry.

if it's special and cannot be removed, there should be a message and deletion from storage.cfg should not happen at all, as it's inconsistency between on-disk configuration and what's shown in webgui and being active.

you should perhaps add an error message and not remove it from configuration, if it's special entry. having a comment with it in storage.cfg would also be helpful and clarify things