mount vz directory to different partition?

[pixelplumber]

Hi, I'm a new user to proxmox, interested in moving over from an existing openvz setup.

On our current system, / is on an 80GB raid 1 and /var/lib/vz is on a separate 750GB raid 10 (1+0) array. The proxmox installer sets up everything on a single volume group (which would end up on our 80GB raid1), but I'd like to place all of the VZ data on the raid 10 partition as we have it now.

My plan is to mount a second volume group manually via fstab to /var/lib/vz/ after install.

Is this configuration likely to get clobbered/left alone on upgrades of pve?

when using snapshots for backup, I'm guessing I have to make sure the requisite free space in the volume group is on the raid 10 array where /var/lib/vz will be mounted, not the raid 1 array where / is?

Cheers.

 

[pixelplumber]

<slaps forehead>

I see proxmox already installs /var/lib/vz to its own LV, so if I want that on our RAID 10 I think I just need to bring that in as a PV and pvmove the data LV over.

 

[dietmar]

My plan is to mount a second volume group manually via fstab to /var/lib/vz/ after install.

should work without problems (just copy the contents of /dev/pve/data to the new LV)

Is this configuration likely to get clobbered/left alone on upgrades of pve?

we will not touch that configuration.

when using snapshots for backup, I'm guessing I have to make sure the requisite free space in the volume group is on the raid 10 array where /var/lib/vz will be mounted,

Yes (our installer reserves 4GB for example)

 

[dietmar]

I see proxmox already installs /var/lib/vz to its own LV, so if I want that on our RAID 10 I think I just need to bring that in as a PV and pvmove the data LV over.

I would not mix PVs with different speed/raid level.

 

[pixelplumber]

Thanks Dietmar, I will make sure that's the case.

And I've just noticed in playing around with LVM setups that if /dev/pve/data is moved to another VG, make sure that is not the same VG used for Virtual Disk LVM groups under the new storage model.

As when you go to delete a LVM Virtual Disk from a KVM machine, proxmox tries to deactivate the whole VG which will fail (code 5) as the data LV is still mounted. So I need to use two VGs, one for the openvz stuff in /var/lib/vz and one for the storage model stuff.

Admittedly something that won't happen if you stick to the default proxmox way.

 

[dietmar]

As when you go to delete a LVM Virtual Disk from a KVM machine, proxmox tries to deactivate the whole VG

I don't think I do that - seems not logical at all.

 

[pixelplumber]

I don't think I do that - seems not logical at all.

Its probably because of my faffing about and doing things a non-standard way in terms of how proxmox is set up.

The exact error I got was:

ERROR: command '/sbin/vgchange -aln storage' failed with exit code 5

I've moved the standard 'data' LV from the standard 'pve' VG on the RAID 1 controller to my own 'storage' VG on my RAID 10 controller.

Creating a LVM storage definition (called 'testing' - for virtual disks) on the storage page in the proxmox gui pointing at my storage VG works. I can add kvm virtual disks here happily and remove them. But I can't go back and delete the 'testing' LVM defintion from the storage page in the proxmox gui because that is when I get the error again (even when there are no kvm virtual disks).

I'm guessing that to remove the storage defintion from the proxmox gui its wanting to lock the VG? That makes sense as you probably don;t want to be able to delete a storage definition if you still have - especially running - KVM virtual disks on there!

So my running VZ VPS's in the moved 'data' LV are locking the 'storage' VG from being deactivated. I guess if I want the most flexibility while keeping my VPS' on the RAID 10 I need to partition the RAID 10 into two PVs and set up two volume groups, one for the data LV and one for backups/virtual disks etc.

I need have a break from all these acronyms!

 

[dietmar]

I'm guessing that to remove the storage defintion from the proxmox gui its wanting to lock the VG? That makes sense

I think that is correct behavior.