Even if LVM itself doesn't care about having a real partition, one reason to create it anyway is to inform partitioning programs that there's "something there." A nightmare scenario is a new sysadmin diagnosing a boot problem on a server, firing up a partitioning program, seeing unpartitioned disks, and concluding that the drive is corrupt.
I see no ...
While you can just create a pv out of raw block device I normally try to avoid it as it can cause confusion as to what the block device is being used for. It may also break some of the auto discover routines that LVM can use if it's missing it's configuration files.
Here's an example of using parted to create a GPT with 1 partition that is the whole drive ...
If you want to do what @James recommended via the cli you can do the following:
$ parted /dev/sde --script -- mklabel msdos
$ parted /dev/sde --script -- mkpart primary 0 -1
This was of course on a smaller HDD (1TB) so as was mentioned in the comments, anything over 2TB will require a different label, and yes you should be using GPT for that.
$ parted /...
Sizes reported by df will be incorrect as they account only for data blocks and miss blocks used internally by the filesystem as well as the reserved blocks.
The easy way is to shrink your filesystem to be smaller than you want by at least 10%. Resize the partition to the size you want then grow the filesystem with resize2fs.
If you want to calculate it by ...
There are two major partitioning schemes in use today: MBR and GPT.
The older, deprecated, and probably still most used one is MBR. However, MBR uses 32 bit to address storage space, using 512 Byte blocks, and 2^32 * 512 Byte are.. 2 TB. So no, you cannot extend an MBR partition over 2 TB. You will need to use GPT for that.
I have never done it myself, but ...
If you create a PV directly on a virtual storage device inside a KVM guest, then you will notice that the logical volumes from the guest are visible on the hypervisor. This can make things quite confusing if you use the same logical volume and volume group names across multiple guests. You may also get some warnings on the hypervisor saying that it can't ...
First of all, I would suggest using RAID6 instead of RAID5. With such a big volume, an URE during the rebuild is likely enough to be worried about it, which would lead to a failed rebuild and lost data.
Then you will need a GPT partition table for a single volume of this size and if performance is the most important factor, I wouldn't use LVM or something ...
The wipefs program lets you easily delete the partition-table signature:
wipefs -a /dev/sda
You still have to stop any process using the device though, such as LVM.
From man wipefs
wipefs can erase filesystem, raid or partition-table signatures (magic
strings) from the specified device to make the signatures invisible
wipefs does ...
Don't use fdisk on a GPT-partitioned disk. Fdisk doesn't know about GPT headers and can in some circumstances overwrite them accidentally (this is rare but can happen), and also doesn't understand any of the extra stuff GPT puts in.
If you want to keep the disk as GPT, use gdisk the way you would use fdisk (they're very similar in their interface). If you ...
Even if in the past I was using MS-DOS disklabel or GPT disklabel for PV, I prefer now to use directly LVM on the main block device. There is no reason to use 2 disklabels, unless you have a very specific use case (like disk with boot sector and boot partition).
The advantage of having LVM directly are:
simplicity - you do not need to use 2 sets of tools
This error means that you can't create a partition of more than 2 TiB on an MBR-partitioned disk. You must use GPT partitioning.
To resolve the issue, create the GPT first:
parted /dev/vdb mklabel gpt
Then continue with your partitioning as normal.
You have two options: move all the misaligned VMs into a datastore created specifically for that misalignment, or fix all the VMs.
If you decide to fix the VMs, my understanding is that you will need to reboot the servers. Here's a Netapp link you can start research on if you decide to take an outage. mbrscan and mbralign are the tools needed.
If you can't ...
I have always simply used parted for this. It works well for changing the disklabel type and adding/removing partitions, especially since it can handle modern large HDDs unlike fdisk.
You can run
$ sudo parted /dev/sda
This will get things started and get you into the parted terminal. You can then run the help command to show all the available commands. ...
I've found that it is easier and safer to do a compressed tar backup, re-install the OS to your new configuration and then restore the files.
Also, no matter how much RAM, I still leave 4GB for swap because you don't know what other machine might be running those disks in the future.
But you are right, 63GB for swap is very high these days.
LVM will only show space that has been formatted for LVM by using pvcreate. Here, it doesn't seem you even have a partition.
1) First you need to create the partition (sda3 I suppose), using your favorite partitioning tool. Assign the LVM tag to the partition. Then, assuming that your 121GB partition is /dev/sda3, you need to run pvcreate /dev/sda3 to get ...
Take a look at GPT fdisk:
Available versions: 0.6.13 (~)0.7.2 (~)0.8.0
Installed versions: 0.8.0(10:58:25 PM 10/12/2011)
Description: gdisk - GPT partition table manipulator for Linux
Assuming that you want to dump partition table from sda to sdb, try ...
First you have to stop all programs which use /var. You can find them with fuser -m /var.
Here you have to take care that you do not kill your SSH session. In order to keep SSH alive it might be necessary to temporarily reconfigure your SSH server to prevent any access to /var.
After that you can unmount your /var partition. And then you can use parted or ...
Cylinders and Heads are irrelevant in this day and age. Stop using the DOS Compatability mode.
Turn DOS Compatability mode off with the '-c' option when you run fdisk.
DOS is dead, let it rest in peace.
loop0p1: device mapper name
(252:2): major:minor of the device
0: starting block of the map (I've never seen anything else than 0)
131072: size of the device in blocks
/dev/loop0: parent device
2048: starting block (block 0 of loop0p1 is block 2048 of loop0)
Also see dmsetup table DEVICE
I'm probably late, but anyway.. Copying partition table from sda to sdb:
Copy mbr and partition table of sda to files:
dd if=/dev/sda of=sda.mbr count=1 bs=512
sfdisk -d /dev/sda > sda.sf
Copy it from files to another drive (here sdb):
dd if=sda.mbr of=/dev/sdb
sfdisk /dev/sdb < sda.sf
If you don't need mbr skip the dd lines.
Parted didn't automatically create a filesystem; you created it.
When you deleted the partition, that's the only thing you deleted. Deleting the partition doesn't delete any of the data within the partition, so there's still a valid ext4 filesystem there. Thus, when you recreate the partition and print the partition table, it can be clearly seen.
SOLVED: one of the admins had installed Spiceworks on the LAN, with access to this user account, and Spiceworks was trying to run these alerted commands to accomplish its monitoring tasks. That's a big relief--apparently no malicious traffic on this one anyway. Here now for posterity.
I've figured out how to do this. The key is kpartx to make the LVM usable by parted outside the VM (so on the Hypervisor host). Then you modify the partition size, then you boot the guest and increase the filesystem.
So if you have a guest named TESTVM that has its storage at /dev/VMS/VIRT-TESTVM, you'd do the following on the hypervisor host:
# kpartx -a /...
I don't think you can do that although you could probably read the file and do it manually, it's an easy format to understand
/dev/sda:120GB:scsi:512:512:msdos:ATA KINGSTON SV300S3:;
If you still have sda in the system then there are other tools yopu can use
For non GPT disks sfdisk works
Disk manufacturers advertise disk sizes in multiples of 1000. That is, a "KB" is 1000 and not 1024 as software people are used to.
For you, it seems that lsblk and gdisk are using the 1024 value but parted is using 1000.
465.5 * 1024 * 1024 * 1024 == 499,826,819,072
499,826,819,072 / (1000 * 1000 * 1000) == 499.826
which maps to the 500 ...
You need these tools:
Install "lsscsi". It's very good to find out what drives you actually
Install "disktype". If you point it on a drive you'll be able
to see what is actually there.
Use "cat /proc/mdstat" to see what's
up with your software raid devices (/dev/md*)
Looks like you have:
/dev/md0 raid1 from 4 16Gb first partitions of every drive ...
Yes you can, but just don't rely on it (i.e. back up your data first!).
The partitions should be adjacent, and for ease's sake you want to be expanding into a partition that comes AFTER the one you want to expand.
Then just use parted on the device, delete both partitions (e.g. sdb1, sdb2), create a new one that spans the entire space, and use resize2fs ...
It has been possible to fix this issue by updating parted to 2.1-21. We have a system based on CentOS in which certain components are source compiled and parted happens to be one. I have not yet tried to explore if there was any bug in the previous parted release.