<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Lvm on the bin</title><link>https://thebin.net/tags/lvm/</link><description>Recent content in Lvm on the bin</description><generator>Hugo</generator><language>en-US</language><lastBuildDate>Mon, 20 Aug 2012 00:00:00 +0000</lastBuildDate><atom:link href="https://thebin.net/tags/lvm/index.xml" rel="self" type="application/rss+xml"/><item><title>Linux-LVM: Resize Partition to Grow LVM Volume Group</title><link>https://thebin.net/2012/08/linux-lvm-resize-partition-to-grow-lvm-volume-group/</link><pubDate>Mon, 20 Aug 2012 00:00:00 +0000</pubDate><guid>https://thebin.net/2012/08/linux-lvm-resize-partition-to-grow-lvm-volume-group/</guid><description>&lt;p&gt;Logical Volume Manager makes the dynamic expansion of file systems dead stupid simple.  However there is a weakness, if you are using a partitioned file system as your Physical Volume (PV) then you will end up needing to expand the file system if you ever need to grow the actual storage.  This can be avoided by using the actual physical device /dev/sda as the PV, however if this is the same volume where your /boot partition lives then you will have no choice but to partition it out since /boot cannot reside on a Logical Volume (LV).  The other way you can avoid this is by simply creating a second partition on the same disk and adding it as a new PV to the existing Volume Group (VG).  This is preferable as there is far less room for error than in this procedure, but I personally find that method a little more confusing to inherit then a straight forward single partition made an LV.&lt;/p&gt;</description></item><item><title>LVM: Using 2TB Volumes for Volume Groups</title><link>https://thebin.net/2012/05/lvm-using-2tb-volumes-for-volume-groups/</link><pubDate>Mon, 28 May 2012 00:00:00 +0000</pubDate><guid>https://thebin.net/2012/05/lvm-using-2tb-volumes-for-volume-groups/</guid><description>&lt;p&gt;Occasionally you will have the need to use physical volumes which exceed the limits of the standard DOS partitioning scheme.  When you run into this a quick fdisk -l will reveal that you will need a new way to partition your disks.&lt;/p&gt;&#10;&lt;p&gt;Fdisk will produce output similar to this…&lt;/p&gt;&#10;&lt;div class="codeblock" data-lang="text"&gt;&#10; &lt;div class="codeblock__bar"&gt;&#10; &lt;span class="codeblock__lang"&gt;text&lt;/span&gt;&#10; &lt;button type="button" class="codeblock__copy" aria-label="Copy code"&gt;&#10; &lt;span class="codeblock__copy-label"&gt;Copy&lt;/span&gt;&#10; &lt;/button&gt;&#10; &lt;/div&gt;&#10; &lt;div class="highlight"&gt;&lt;pre tabindex="0" class="chroma"&gt;&lt;code class="language-text" data-lang="text"&gt;&lt;span class="line"&gt;&lt;span class="cl"&gt;WARNING: GPT (GUID Partition Table) detected on &amp;#39;/dev/sdb&amp;#39;! The util fdisk doesn&amp;#39;t support GPT. Use GNU Parted.&#10;&lt;/span&gt;&lt;/span&gt;&lt;span class="line"&gt;&lt;span class="cl"&gt;&#10;&lt;/span&gt;&lt;/span&gt;&lt;span class="line"&gt;&lt;span class="cl"&gt;WARNING: The size of this disk is 2.3 TB (2290828181504 bytes).&#10;&lt;/span&gt;&lt;/span&gt;&lt;span class="line"&gt;&lt;span class="cl"&gt;DOS partition table format can not be used on drives for volumes&#10;&lt;/span&gt;&lt;/span&gt;&lt;span class="line"&gt;&lt;span class="cl"&gt;larger than 2.2 TB (2199023255040 bytes). Use parted(1) and GUID&#10;&lt;/span&gt;&lt;/span&gt;&lt;span class="line"&gt;&lt;span class="cl"&gt;partition table format (GPT).&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&#10;&lt;/div&gt;&#10;&lt;h2 id="use-parted-to-create-a-partition-using-the-whole-disk"&gt;Use Parted to Create a Partition Using the Whole Disk&lt;/h2&gt;&#10;&lt;p&gt;Parted is able to handle large volumes which are not able to be modified with fdisk.  Here we are going to launch parted, and then create the partition with a size of 1 -1 which means that it will use it all until it gets to the end.  You can additionally specify the number in megabytes, so 1 1024 would start at 1 and go until 1024 giving you a 1GB partition.&lt;/p&gt;</description></item><item><title>Bash: Duplicate Logical Volume Configuration for a Volume Group</title><link>https://thebin.net/2012/04/bash-duplicate-logical-volume-configuration-for-a-volume-group/</link><pubDate>Mon, 30 Apr 2012 00:00:00 +0000</pubDate><guid>https://thebin.net/2012/04/bash-duplicate-logical-volume-configuration-for-a-volume-group/</guid><description>&lt;p&gt;I recently ran into a situation where I needed to create a large number of Logical Volumes for a server replacement situation.  I could have done some manual data input, but why not take the opportunity to quickly write a script to do the hard work for me?&lt;/p&gt;&#10;&lt;p&gt;For my situation this was a server that pulls data from other servers in order to optimize getting that data to tape.  So we had 2 VGs, one for the system and one for the data we wanted to move.  We planned on simply performing a rsync to move the data itself, but the volumes had to be pre-staged.&lt;/p&gt;</description></item><item><title>Linux-KVM: Converting Raw Disk Images to LVM Logical Volumes Redux</title><link>https://thebin.net/2011/11/linux-kvm-converting-raw-disk-images-to-lvm-logical-volumes-redux/</link><pubDate>Mon, 07 Nov 2011 00:00:00 +0000</pubDate><guid>https://thebin.net/2011/11/linux-kvm-converting-raw-disk-images-to-lvm-logical-volumes-redux/</guid><description>&lt;p&gt;This really is an update to my previous article “&lt;a href="http://blog.allanglesit.com/2011/03/linux-kvm-converting-raw-disk-images-to-lvm-logical-volumes/"&gt;Linux-KVM: Converting Raw Disk Images to LVM Logical Volumes&lt;/a&gt;“, but the process is significantly different and thus requires more explaining than a simple inline update would do it justice.  Now the big flaw with my first article was that by using dd on the hypervisor level, we are opening ourselves up to unintentional data loss due to incompetence or even a very competent slip of the finger.&lt;/p&gt;</description></item><item><title>Linux-KVM: Managing Disk Images</title><link>https://thebin.net/2011/03/linux-kvm-managing-disk-images/</link><pubDate>Wed, 16 Mar 2011 00:00:00 +0000</pubDate><guid>https://thebin.net/2011/03/linux-kvm-managing-disk-images/</guid><description>&lt;p&gt;Disk images have long been the traditional form of storage for virtualized environments, they are essentially containers in the form of a file on the host’s file system.  These files can be either fully allocated or sparsely allocated at time of disk creation, a fully allocated 20GB disk image will take up 20GB of storage on the host file system, a sparsely allocated 20GB disk image will only take up as much storage on the host file system as has actually been written inside of the disk, so if you have a newly created sparse file the file will be just a few KB in size.&lt;/p&gt;</description></item><item><title>Linux-KVM: Converting Raw Disk Images to LVM Logical Volumes</title><link>https://thebin.net/2011/03/linux-kvm-converting-raw-disk-images-to-lvm-logical-volumes/</link><pubDate>Wed, 09 Mar 2011 00:00:00 +0000</pubDate><guid>https://thebin.net/2011/03/linux-kvm-converting-raw-disk-images-to-lvm-logical-volumes/</guid><description>&lt;p&gt;Linux Logical Volume Manager provides a better method for managing your disks in the home and even more so in the datacenter.  I briefly outlined some of the benefits afforded us by LVM2 in a previous article &lt;a href="http://blog.allanglesit.com/2011/03/linux-lvm2-flexible-local-storage-management/"&gt;Linux LVM2: Flexible Local Storage Management&lt;/a&gt;.  In this article I will provide you with some very simple steps and scenarios to migrate your existing KVM VMs to LVM2 Logical Volumes.&lt;/p&gt;&#10;&lt;p&gt;In this article I am going to make an assumption that your disk images are raw disk images and that you are not using qcow2, vhd, vdi, vmdk or any other disk image format.  Additionally this process should work for a physical or RAID device as well, though I have not verified that.&lt;/p&gt;</description></item><item><title>KVM Guests: Using Virt-Install to Import an Existing Disk Image</title><link>https://thebin.net/2011/03/kvm-guests-using-virt-install-to-import-an-existing-disk-image/</link><pubDate>Tue, 08 Mar 2011 00:00:00 +0000</pubDate><guid>https://thebin.net/2011/03/kvm-guests-using-virt-install-to-import-an-existing-disk-image/</guid><description>&lt;p&gt;In my previous article &lt;a href="http://blog.allanglesit.com/2011/03/kvm-guests-using-virt-install-to-install-debian-and-ubuntu-guests/"&gt;KVM Guests: Using Virt-Install to Install Debian and Ubuntu Guests&lt;/a&gt; we identified how we can use the virt-install command to create a KVM VM and instead of using an iso or physical cd for the install media we can instead use a boot image from an apt mirror via http.  Now obviously this does not harness the true power of the virt-install command.  Today we will discuss how we can take an existing disk image and import it as a VM with the appropriate devices, this would most commonly be done with sysprepped Windows images, to speed up deployment. Though these instructions will easily work with any OS.&lt;/p&gt;</description></item><item><title>Linux LVM2: Flexible Local Storage Management</title><link>https://thebin.net/2011/03/linux-lvm2-flexible-local-storage-management/</link><pubDate>Tue, 01 Mar 2011 00:00:00 +0000</pubDate><guid>https://thebin.net/2011/03/linux-lvm2-flexible-local-storage-management/</guid><description>&lt;p&gt;Linux LVM provides a different way of looking at storage.  On the server side this provides much more flexibility than standard disks with partitions.  It allows us to migrate from old to new storage as well as expand the available storage to a particular file system easily (assuming that there is free space available).&lt;/p&gt;&#10;&lt;p&gt;Basically LVM abstracts the physical storage by creating Physical Volumes (PV), and each PV is divided into Physical Extents (PE) which are a consistent size.  Physical Volumes are then added to a Volume Group (VG) which essentially pools all of the PE on all member PV.  Once you have a VG you can then create a Logical Volume (LV) which can be formatted and used as if it were a physical disk, the difference is that the LV can be expanded as many times as needed up until all PE have been allocated within the VG.  In this event you could then simply add another PV to the VG, which would make available additional PE to be added to a LV.&lt;/p&gt;</description></item></channel></rss>