Bug in PVE GUI report of space, and a more question

cesarpk

Well-Known Member
Mar 31, 2012
770
3
58
Hi to all

Due to that i will run a VM with a database, and for get a better I/O performance, i will use LVM and not LVM-Thin, so i created a small partition of 50 GB for the installation of PVE (after, i will create some LVM partitions), then, after my installation and respective update/upgrade, i run this command:
lvextend -l +100%FREE /dev/pve/root

And after of that... Oh, surprise, i get differents reports about of root space....
- lvdisplay says this: "LV Size 47.74 GiB"
- lvscan says this: "ACTIVE '/dev/pve/root' [47.74 GiB] inherit

- PVE GUI say this: HD space(root)14.24% (1.70 GiB of 11.93 GiB)

So, my question is: Why the PVE GUI tell me that i have 11.93 GiB and the others say that i have 47.74 GiB of total space in the root volume?

The second question: If i only will use KVM and not CT, and also i will do live backup, will I need space available in the VG where the virtual disk is working?
Note: Also i have planned use the QEMU Agent, but in anyway i guess that i will not need space available in the VG where the virtual disk is working.

BR
Cesar
 
Hi!

Could it be that you forgot to resize the root file system to the new underlying (lvm) block device size?

see if
Code:
lsblk
df -h

report different size, in your case lsblk should report root as 47.74 and df -h should report still the old 11.93 as the FS was not resized.

You can do this afterwards with resize2fs on ext2/3/4 based filesystems, this works online:
Code:
resize2fs /dev/pve/root

Or for the future, with lvmextend there is also an option for doing that automagically, namely -r or --resizefs
 
The second question: If i only will use KVM and not CT, and also i will do live backup, will I need space available in the VG where the virtual disk is working?
Note: Also i have planned use the QEMU Agent, but in anyway i guess that i will not need space available in the VG where the virtual disk is working.

I may not understand the question correctly, but you would need the space which the VM disk itself occupates. If you use snapshots then yes, the VMs LV might actually need more space than the size.
Take a VM with 10GB disk, for example. If I write the whole disk full of data and then make a snapshot, then write the whole disk again full of completely other data, now it would need 20 GB, 10 for the disk itself and 10 for the data of the snapshot.
But this would be the worst case szenario, normally:
1) a VMs disk gets not 100% full, this would indicate other problems
2) if a snapshot is made the chance that everything gets rewritten to completely other data blocks afterwards is really small, normally you have a more linear change in data which then only needs a few percent of more disk space.

But with qemu agent the guest itself should freezes its FS so you no external snaphshot gets made, AFAIK, you could be good with no space left in the VG.

Else, without qemus guest agent a live backup uses snapshots so you may want a little extra space left, how much is hard to tell.
It depends on how long the backup needs and how much gets written during this time.

Anyhow, a little space as reserve is surely not bad :)

The QEMU guest agent runs inside the VM so you need no extra free space outside of the VM for it to run.

Oh, and as both question differ quite a bit it could be better to open a thread for each one the next time :)
 
Hi!

You can do this afterwards with resize2fs on ext2/3/4 based filesystems, this works online:
resize2fs /dev/pve/root

Or for the future, with lvmextend there is also an option for doing that automagically, namely -r or --resizefs

Oh, excuse me please, it was a big mistake of mine... :-(
 
Else, without qemus guest agent a live backup uses snapshots so you may want a little extra space left, how much is hard to tell.
It depends on how long the backup needs and how much gets written during this time.

Thanks for your prompt reply, i was referring to this case.

But for PVE 3.x version, Tom or Dietmar (I do not remember now which of the two) told me that for KVM live backup, space free in the LVM-VG isn't necessary to have, due to that it do not use a LVM-snapshot, and that if i have containers, for the live backup will use the free space of the LVM-VG.
In PVE 3.x version, for live backups, also i was reading how does it work QEMU-Backup, that is more fast that a live backup with LVM, due to that it is done in less phases

Then, according to your reply, in PVE 4.x version, the mode of backup is with LVM and not with QEMU?, and the live backup will be more slow?

Oh, and as both question differ quite a bit it could be better to open a thread for each one the next time
Oh, OK, i will do.

BR
Cesar
 
But for PVE 3.x version, Tom or Dietmar (I do not remember now which of the two) told me that for KVM live backup, space free in the LVM-VG isn't necessary to have, due to that it do not use a LVM-snapshot, and that if i have containers, for the live backup will use the free space of the LVM-VG.
In PVE 3.x version, for live backups, also i was reading how does it work QEMU-Backup, that is more fast that a live backup with LVM, due to that it is done in less phases

If they told you so then this is highly probably correct. I glanced quickly in the code and it looks like we really do not make snapshots on storage level with VM (which also makes sense, now that I think more over it).
Actually I'm quite sure now that this is true. So you should be good with no extra space (in 3.X and 4.X) at least with VMs only. Sorry for the confusion.
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!