Operating systems





Figure A


Figure B


Figure C


Figure D


Figure E


Figure F




Figure G shows the command string used for a simple lvcreate.

Figure G






Hi scott ,

                I am not able to create vg or lvm on a HA machine(i.e a server which has 2 physical machines in one),i have one 1 TB SCSI hard drive.The HA machine supports SAS drives,using converter  i have connected the 1 TB hardisk. 

While installing linux OS,i am not able create a LVM group and LVM.I get a error as choose a physical HD /RAID . Even in command mode there is no options to create LVM group.(i was installing RHEL 5.7).

I need to install around 14 OS in that hardisk.So i need a LVM and one extended partation.Can you help me please . 


If you get the message above when you try to create a PV with 'pvcreate' you don't (generally) need the '-ff' option. That's a sledgehammer, usually needed when you're in the unenviable position of having to string back together a busted up LVM group. (I've done this... it ain't pretty.) Run 'pvs' to get a quick list of PVs on your system. (And yes, 'vgs' and 'lvs' give you a quick list of VGs and LVs on your system. One helpful form of the last command is lvs -a -o +devices which will not only list your LVs, but it will show you what PVs each LV is using. VERY useful info when you're moving your PEs from disk to disk.) So if 'pvs' shows that your intended PV was previously a PV, you can enter pvremove /dev/sdXY to take it out, then put it back in again with 'pvcreate /dev/sdXY'. No need for sledgehammers. It's most handy to use LVM with RAID, in which case you'll be creating PVs from RAID md's. It all works the same, you just use the form pvcreate /dev/mdX vgextend db_arch /dev/mdX and you've added a RAID disk (typically a RAID-1 set) to your VG to create/extend LVs with. Aside from the redundancy, it makes your LVM more bulletproof and gives you more flexibility to do things such as migrate to other disks and even split a RAID-1 array to move your entire FS to a new machine (or location) -- while still using the existing system (which stays in place on a degraded RAID-1 set. (You can add new mirrors later.) Fun stuff... :^)


Often when you write the partition table back out, you'll get a notification that the kernel couldn't properly figure out what you just did to the disk, and so it will continue to use the old partition table -- and that you'd better not try to do anything to your disk until you've rebooted... That's a pain --obviously-- but often you can avoid this by entering partprobe when you get this message. It tells the system to re-probe the disk (as though it were in the process of booting up) and often --not always-- will get the kernel to clear its head and "get" your new partition configuration. That can save an undesirable reboot...


It would be mkfs -t ext4 /dev/db_arch/archive01 However, this will create a (default) 5% reserve ("for the superuser") -- it's meant to be emergency space for an OS to use if your logs, etc. fill up your OS partition. You generally don't need this for a data-only partition. (I still allow 1%; it saves 4% of my disk space and makes it available for my use.) You can control this overhead with the '-m' switch: mkfs -t ext4 -m 1 /dev/arch_db/archive01 will reserve only 1% instead of 5%. (Some use '-m 0' and allow no reserve.) I also follow this up with an 'fsck' on the created LV "just to be sure".


It appears the last fina,l but critical to use the volume, step is mentioned but the actual command line example is missing ?? Otherwise, an excellent step-by-step outline.

Editor's Picks