When Liraz first wrote that post (that I linked to above) I was struggling with LVM and couldn't quite get my head around it... That post made it all click for me.

I still wouldn't call myself an expert, but have fiddled around with LVM quite successfully now on a number of occasions (both within TKL and on a couple of PVE servers) and find it pretty straight forward now...

If you are having specific issues perhaps post about them and we might be able to help with the details...?

I am also experiencing the same issue. It was working fine at first but after shutting down and powering my device up, it didn't work as it used to.

PVE (headless hypervisor server with Web UI) is the gear IMO... I use it at home and for a client and performance is incredible IMO (even on old hardware).

At home I have it installed installed on a 6yo desktop PC; currently have about 20 VMs running on it and performance is incredible consider the old specs.

For my client (my ex workplace); they have much better hardware but still only workstation grade (not 'proper' server hardware) and it's great, reliable and very low maintenance.

PVE supports both OVZ (for Linux) and KVM (for all OS inc Windows). Also TKL OVZ templates are available for download direct through the PVE Web UI! IMO the performance of OVZ containers can not be matched (although I have heard that LXC performance is the same - just haven't confirmed that first hand yet).

I'm sorry for hijacking your thread too Greg! Please post back if/when you want some more help/info...

@Snickasaurus - When I originally set up my server at home I was going to use Xen, then I found that too painful so looked at XenServer, but at that point it was still proprietary which turned me off. When I found PVE I loved it! :)

Now XenServer is fully open source, I wouldn't be surprised if it's popularity grows... I recall it looked quite nice and that was a few years ago now...

FWIW my home PVE server is a Core 2 Duo e6400 (with 8GB RAM) and it runs sweet. Some more RAM wouldn't go astray but the CPU is totally fine for my (light) workload (mostly media/file server, a couple of game servers fro my son, a couple of dev servers for myself and my son and otherwise mostly just testing...

I don't understand why you don't just use the same LV for the whole system and add your additional drives to it...? As per described in the blog post I linked to in my first post in this thread... I know that specifically relates to VMs but the theory is exactly the same for real HDDs - I successfully used those instructions when I added additional HDDs to my PVE setup (PVE also uses LVM).

Perhaps I am missing something in your setup scenario, but to me the most logical and straightforward way to do it would be to install from ISO to one of the HDDs (Possibly the 120GB, but wouldn't really matter) then once setup is complete, add the other drives to the LV... Done...!

I guess if you wish to backup the data only (not the rest of the OS) using something like rsync, then having the data separate from the OS makes some sense (although as long as it's in a separate folder it wopuldn't make a huge difference).

If you are planning on making use of TKLBAM though it's probably irrelevant (by default TKLBAM will only backup important OS settings and the data).

If you had no plans for backups (and this setup is only for testing and/or hosting non-important data) then I wouldn't think that it would matter either...

The hardware shouldn't matter at all. AFAIK LVM will happily use IDE and/or SATA (and/or SCSI and/or USB sticks/drives and/or pretty much any other read/write storage device).

I had to google Windows dynamic volume to get an understanding of what that was. Once I did then I can say that generally LVM is somewhat similar to Windows 'simple volumes' (if you use LVM with only one disk) and/or 'spanned volumes' (with multiple disks). There are 3 layers to LVM:

• Physical Volumes [PV]: As the names suggests these relate to the physical harddrives. They can consist of whole unformatted drives (as I used in my example above e.g. /dev/sdb etc) or can be individual partitions (e.g. /dev/sdb1 etc).
• Volume Groups [VG]: These are one or more groups of PVs.
• Logical Volumes [LV]: These are somewhat like partitions on normal physical drives.

In the case of a standard default install of TKL to a single drive it goes something like this (not to scale):

MNT:  [--/boot--][------/(root)----------][--swap--][*]
LV:              [--------root-----------][--swap--][*]
VG:              [--------------turnkey---------------]
PV:   [/dev/sda1][-----------/dev/sda5----------------]
HDDs: [------------------/dev/sda---------------------]
*-unused space to allow for snapshots

Note I added the MNT line to show mount points; i.e. /boot is mounted but is not part of the LVM; also that LVM root (aka turnkey-root; often logical volumes are expressed as [VG]-[LV]) is loaded as / (i.e. the filesystem root). /boot is a separate partition as the OS needs to start loading before LVM is up and running.

The scenario I am suggesting would look something like this (not to scale):

MNT:  [--/boot--][-------------------/(root)---------------------][--swap--][*]
LV:              [---------------------root----------------------][--swap--][*]
VG:              [--------------------------turnkey---------------------------]
PV:   [/dev/sda1][/dev/sda5][-------/dev/sdb--------][--------/dev/sdc--------]
HDDs: [------/dev/sda------][-------/dev/sdb--------][--------/dev/sdc--------]
*-unused space to allow for snapshots

An alternate scenario (more like what you are suggesting) could look like this (not to scale):

User: [--/boot--][--/-][swap][*][------------------/srv/storage----------------][*]
LV:              [root][swap][*][----------------------data--------------------][*]
VG:              [---turnkey---][--------------------storage----------------------]
PV:   [/dev/sda1][--/dev/sda5--][/dev/sda6][-----/dev/sdb-----][-----/dev/sdc-----]
HDDs: [-------------/dev/sda--------------][-----/dev/sdb-----][-----/dev/sdc-----]
*-unused space to allow for snapshots

In this scenario you will need to add the remainder of sda along with all of sdb and sdc to a new VG (which I called 'storage'). Then create your new LV within that (I called it 'data') and mount it wherever you want (I used /srv/storage as an example).

You could just make your data storage LV within the turnkey VG, however I don't think that there is any advantage to that usage (IMO you'd be better off just leaving the data and OS together as per the middle suggestion).

Does that give you a little more clarity? Or am I just confusing you more...?

The page you sent me probably still has some relevance, but in my (somewhat limited) experience I have never had need to make a separate partition for anything (other than /boot and swap). On Linux Desktops though I have been known to set up a separate /home partition. That allows for OS update without needing to start again... It has also caused me the odd issue though (different config for updated software for example)...

You are most welcome on the help. Hope you can get your systems up and running! :)

Are there perhaps issues with those disks... You mentioned they were 2nd hand. Perhaps they've died (although seems unlucky that they both go at the same time...)

I was going to double check on my PVE server but I was trying to get a Xen server hypervisor running nested on top of KVM (for testing) and it seems I've broken KVM so can't currently do any testing. Sorry Greg...

The only other possibility that springs to mind is that the device names may have changed (i.e. not /dev/sdb). Although that seems unlikely as surely at least one of them would have still been the same..Also lookng again it's complaining about both /dev/sdb and /dev/sbd1 - AFAIK you can only use one or the other (device name or partition name), not both...

FWIW your fstab looks fine at a glance.

Yes fstab is basically like a manually configure automount conf file. LVM should know how/which logical volumes relate to the PVs. So for example here is my Proxmox server fstab (I'd give you a better TKL example but as I said my Proxmox server is currently sort of broken...)

root@proxmox:~# cat /etc/fstab
# <file system> <mount point> <type> <options> <dump> <pass>
/dev/pve/root / ext3 errors=remount-ro 0 1
/dev/pve/data /var/lib/vz ext3 defaults 0 1
UUID=8a31839f-b638-48e1-a4f5-6e35e4d60c6a /boot ext3 defaults 0 1
/dev/pve/swap none swap sw 0 0
proc /proc proc defaults 0 0
/dev/pve2/data2 /media/pve2 ext4 defaults 0 1

The current LVs:

root@proxmox:~# lvscan
  ACTIVE            '/dev/pve2/data2' [1.66 TiB] inherit
  ACTIVE            '/dev/pve/swap' [7.00 GiB] inherit
  ACTIVE            '/dev/pve/root' [96.00 GiB] inherit
  ACTIVE            '/dev/pve/data' [812.02 GiB] inherit

The VGs:

root@proxmox:~# vgscan
  Reading all physical volumes.  This may take a while...
  Found volume group "pve2" using metadata type lvm2
  Found volume group "pve" using metadata type lvm2

And the PVs:

root@proxmox:~# pvscan
  PV /dev/sdb1   VG pve2   lvm2 [465.75 GiB / 0    free]
  PV /dev/sdb2   VG pve2   lvm2 [465.76 GiB / 0    free]
  PV /dev/sdb3   VG pve2   lvm2 [465.74 GiB / 163.01 GiB free]
  PV /dev/sdb4   VG pve2   lvm2 [465.76 GiB / 0    free]
  PV /dev/sda2   VG pve    lvm2 [931.01 GiB / 16.00 GiB free]
  Total: 5 [2.73 TiB] / in use: 5 [2.73 TiB] / in no VG: 0 [0   ]

This is a bit of an odd setup I know but it is mostly because I had a heap of 500GB drives that i have since replaced and it was before I totally understood what I was doing so just moved the PVs to partitions on the new 2TB disk.

I hope it is of some value to you...

Also one other thing I just noticed is that you don't have a 'real' partition as /boot. Now AFAIK theoretically you can do what you've done, but best practice is to use a 'normal' real partition for boot (ideally the first partition on the first disk). Otherwise you can have issues. I wonder if your problems is a result of that? Perhaps I wasn't clear enough on that... I hope I haven't confused you...

Also FWIW here is my disks/partitions as per fdisk (notice the warnings/errors - these can be safely ignored, it's just because fdisk doesn understand/can't read the LVs):

root@proxmox:~# fdisk -l

Disk /dev/sda: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders, total 1953525168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0005419c

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        2048     1048575      523264   83  Linux
/dev/sda2         1048576  1953523711   976237568   8e  Linux LVM

Disk /dev/sdb: 2000.4 GB, 2000398934016 bytes
255 heads, 63 sectors/track, 243201 cylinders, total 3907029168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1              63   976751999   488375968+  8e  Linux LVM
/dev/sdb2       976752000  1953520064   488384032+  8e  Linux LVM
/dev/sdb3      1953520065  2930255999   488367967+  8e  Linux LVM
/dev/sdb4      2930256000  3907024064   488384032+  8e  Linux LVM

Disk /dev/mapper/pve-root: 103.1 GB, 103079215104 bytes
255 heads, 63 sectors/track, 12532 cylinders, total 201326592 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Disk /dev/mapper/pve-root doesn't contain a valid partition table

Disk /dev/mapper/pve2-data2: 1825.4 GB, 1825361100800 bytes
255 heads, 63 sectors/track, 221920 cylinders, total 3565158400 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Disk /dev/mapper/pve2-data2 doesn't contain a valid partition table

Disk /dev/mapper/pve-swap: 7516 MB, 7516192768 bytes
255 heads, 63 sectors/track, 913 cylinders, total 14680064 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Disk /dev/mapper/pve-swap doesn't contain a valid partition table

Disk /dev/mapper/pve-data: 871.9 GB, 871895138304 bytes
255 heads, 63 sectors/track, 106001 cylinders, total 1702920192 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Disk /dev/mapper/pve-data doesn't contain a valid partition table