Volume Group creation via GUI breaks GPT

[pjdouillard]

Hello,
I am using the GUI to create my LVM/LVM-Thin but I found that GPT is being mangled somehow after the operation.
Before creating a Volume Group, the GUI shows the disks being GPT which is correct.
After the creating a VG, GUI now reports that the disk is not GPT anymore.
From the CLI, gdisk reports that GPT tables are different and that the disk should be repaired - which I do to fix the issue.

Some questions: Although I am able to create LVM/LVM-Thin from the command line, the GUI reports that the new partitions is 100% used already, but from the CLI all the tools reports the space as free.

A couple of questions:
-Is it safe to use the GUI or is this a know problem?
-Why aren't there more tools in the GUI to adjust PVS, VGS, LVS and mkfs ? You can create stuff, but you can't delete/remove/fix anything and have to resort to CLI all the time for even basic stuff. Or am I missing them somehow?

I am a new user of Proxmox and was impressed by the sheer power it provides and ease of clustering without having to depend on 'appliance' to control your nodes or to provide more features. So I decided to give Proxmox a GO and try to run my lab on it and once satisfied and confortable managing it, to start to replace 'other' virtualization framework at some other businesses.

Even though I am starting with VE 6.1, there are basic stuff that is missing from the GUI. For example, more control over disks and file system for basic stuff should be there. Same thing with the networking. Too much stuff needs to be done on the command line and this is more error prone even when you know what you are doing - that's the goal of a GUI : to simplify simple stuff, made the operation of the system smoother and concentrate on the actual real tasks to be performed in vms ecosystem.

Thx for any help!
P.J

 

[dcsapak]

Some questions: Although I am able to create LVM/LVM-Thin from the command line, the GUI reports that the new partitions is 100% used already, but from the CLI all the tools reports the space as free.

the output of 'pvs', 'vgs', 'lvs' would be helpful here

as for your question about gpt, when a lvm(thin) pv/vg/lv gets created, we use the whole disk, there is no point in creating a partition on it,
but this probably overwrites only the beginning of the disk, so gdisk checks the backup table and sees a mismatch

about the general gui disk management inquiry, the idea is that a user can quickly and without much hassle (iow. not many things to configure; sane defaults) create
a storage type on new and unused disks from the gui

the removal of data is always very risky, and we did avoid putting such options in the gui, to prevent accidental data destruction
also we do not really want a full blown partition/lvm/zfs manager in the gui, there much better (cli) tools that accomplish already that
but we could probably add some features here and there, you could open an enhancement request here: https://bugzilla.proxmox.com or even try to contribute some patches yourself (if you want)

Same thing with the networking. Too much stuff needs to be done on the command line

what exactly did you have to do on the commandline? the last few installs i did only need the gui for the networking
(as i said above, please open enhancement requests if there is some concrete feature you miss)

hope this answer helps

 

[pjdouillard]

what exactly did you have to do on the commandline? the last few installs i did only need the gui for the networking
(as i said above, please open enhancement requests if there is some concrete feature you miss)

hope this answer helps

Thank you for the reply.

If you need to setup jumbo frames (or any specific MTU for the matter), you need to edit configuration files instead of just have an 'option box' (à-la Freenas) that let you specify that easily.
And I must say that I am a bit lazy nowaday as having configured everything in my career from the command line since the 80s, I'd hope that the future generations would find some ways to limit over use of the command line for simple tasks. It's not a big deal, but when your focus is on something else but your getting slow down by pesky obvious parameters that should be available in the GUI makes the journey less fun.

Your explanation for the GPT issue is exactly that.

 

[jimmymcheung]

the output of 'pvs', 'vgs', 'lvs' would be helpful here

as for your question about gpt, when a lvm(thin) pv/vg/lv gets created, we use the whole disk, there is no point in creating a partition on it,
but this probably overwrites only the beginning of the disk, so gdisk checks the backup table and sees a mismatch

about the general gui disk management inquiry, the idea is that a user can quickly and without much hassle (iow. not many things to configure; sane defaults) create
a storage type on new and unused disks from the gui

the removal of data is always very risky, and we did avoid putting such options in the gui, to prevent accidental data destruction
also we do not really want a full blown partition/lvm/zfs manager in the gui, there much better (cli) tools that accomplish already that
but we could probably add some features here and there, you could open an enhancement request here: https://bugzilla.proxmox.com or even try to contribute some patches yourself (if you want)


what exactly did you have to do on the commandline? the last few installs i did only need the gui for the networking
(as i said above, please open enhancement requests if there is some concrete feature you miss)

hope this answer helps

Coming back from 2023, I got the same confusion. According to web, having GPT is good from storage size above 2TB, and seeing the default disk (where pve is created and booted) has GPT partition, while additional disk lost the GPT label after it is in a vg, is it safe to leave it like this? Because this additional disk is hardware RAID, I might upgrade the disks so that it's volume become larger.

 

[RolandK]

> but this probably overwrites only the beginning of the disk, so gdisk checks the backup table and sees a mismatch

@dcsapak , if the gui tool overwrites gpt with pvs or whatever and doesn't care about proper gpt purge, i think this is not good. if gpt is being overwritten with other "partitioning" tool, gpt or whatever is on disk before that should better be wiped thoroughly (wipefs...) to avoid misunderstanding or confusion.

>the removal of data is always very risky, and we did avoid putting such options in the gui, to prevent accidental data destruction

yes, but if you can kill/overwrite a gpt via gui with new partitioning/volume information, then it better should be done right.

it's dangerous to have gpt backup table in place when lvm2 thinks it would own that disk alone

​