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 Linux LVM2: Flexible Local Storage Management. In this article I will provide you with some very simple steps and scenarios to migrate your existing KVM VMs to LVM2 Logical Volumes.
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.
This process is primarily executed by using a command called dd. This program is used to perform low level read and write operations to block devices (read storage). It doesn’t care about the file system and does not care about your data. Now this is actually a good thing because the operations we are going to have it do would most likely be seen as erroneous operations for a higher level program, but dd just quietly does it. Now anyways for the uninitiated dd is supremely powerful and exponentially more dangerous. It will destroy your data leaving you red-faced and wishing you were dead if you do not fully understand everything you are doing… That said if this is your first time using dd (or if you are rusty in the slightest – which you are since you are reading this) you better be doing this in a test environment (with not even a single production or important byte) until you completely understand the full command. If you are supremely confident in your abilities and my documentation then backup your data before proceeding…
Now in my case I use this as a base Windows Image, it is sysprepped and ready for action. You could be doing this simply to better manage your storage, it does not matter at this level. You simply are cloning the disk, but please keep in mind you are creating a carbon copy of the original disk image, if it is not a sysprepped Windows image you will need to ensure that both are not started at the same time until one or both is made unique or you could have network conflicts.
Our Image File
# kvm-img info /kvm/images/disk/vmname_boot.img image: vmname_boot.img file format: raw virtual size: 40G (42949672960 bytes) disk size: 9.8G
Now a couple of things to note our virtual size is the max size that the guest os is aware of, the disk size is the size the disk has expanded to on the host. In order for the dd to work you must create an LV that is the same (exactly by block) or larger. For simplicity I am going to create a 50G LV.
Create the Logical Volume
# lvcreate -L50G vg_name -n vmname_boot
Image the New Logical Volume
# dd if=/kvm/images/disk/vmname_boot.img of=/dev/vg_name/vmname_boot
This one command can wipe out a file system if you are not careful. The most important part is that you KNOW where the disk is going to. The out-file parameter or of=/dev/vg_name/vmname_boot means that that device in its current state will be completely destroyed. That is great if the device is the LV you created, not so great if it is your raw image file or even worse part of your filesystem. The in-file or if=/kvm/images/disk/vmname_boot.img is what the out-file will be overwritten with, if you take the wrong file here, it can cause fear and frustration but ultimately you shouldn’t have any data loss. This command will literally copy every block from the disk image file into the LV, so depending on the size it could take some time, but once it is there you will gain a lot of flexibility when it comes to growing your storage and also moving your VMs.
Finally reconfigure your VM to use the new storage and test to make sure everything is still working as expected.