4

Problem

I'm getting a No space left on device error when doing a dd command. I'm trying to move a KVM qcow2 file to an LVM partition and thought that the LVM partition needed to be the same size as the sum of the partitions in the vmbuilder.partition file. This is how it is described in this HowToForge article. Here's the error output:

root@bond:/tmp/zing-UZFgZpj1# dd if=disk0.raw of=/dev/vol/zing bs=1M
dd: writing `/dev/vol/zing': No space left on device
3001+0 records in
3000+0 records out
3145728000 bytes (3.1 GB) copied, 32.5236 s, 96.7 MB/s

I can use the new copy and everything still seems to work fine. I'm assuming I should be worried though. When I use dd to copy it to another file, the size of the file is slightly larger than the LVM partition! See below for details.

Additional details

I'm using KVM and vmbuilder to create the disk image. My vmbuilder.partition file looks like this (a total of 3000MB):

root 2000
swap 1000

So I first create an LVM partition big enough to hold the VM. I thought it was supposed to be the same size as the sum of the partitions, but is this not correct? Should I make it 3001M?

root@bond:~/vmbuilder# lvcreate -L3000M -n zing vol
   Logical volume "zing" created

Then I use vmbuilder to create the disk image:

root@bond:~/vmbuilder# vmbuilder kvm ubuntu -o \
    --templates=/root/vmbuilder/templates \
    --ip=192.168.0.225 \
    --hostname=zing \
    --raw=/dev/vol/zing \
    --part=/root/vmbuilder/appliances/jetty/vmbuilder.partition \
    --pass=7dhsLzUp \
    --dest=/tmp/zing-UZFgZpj1 \
    --user=zing \
    --mem=2048 \
    --firstboot=/tmp/boot-UZFgZpj1.sh \
    --copy=/tmp/copyfiles-UZFgZpj1 \
    --addpkg=jetty ;

When it's done, I convert the qcow2 file to a raw file:

root@bond:/tmp/zing-UZFgZpj1# ls -al
total 447892
drwxr-xr-x 2 root root      4096 2010-03-06 16:51 .
drwxrwxrwt 5 root root      4096 2010-03-06 16:51 ..
-rw-r--r-- 1 root root 458752000 2010-03-06 16:51 disk0.qcow2

root@bond:/tmp/zing-UZFgZpj1# qemu-img convert disk0.qcow2 -O raw disk0.raw
root@bond:/tmp/zing-UZFgZpj1# ls -al
total 891384
drwxr-xr-x 2 root root       4096 2010-03-06 17:32 .
drwxrwxrwt 5 root root       4096 2010-03-06 16:51 ..
-rw-r--r-- 1 root root  458752000 2010-03-06 16:51 disk0.qcow2
-rw-r--r-- 1 root root 3146776576 2010-03-06 17:32 disk0.raw

Lastly, I copy it to the LVM partition:

root@bond:/tmp/zing-UZFgZpj1# dd if=disk0.raw of=/dev/vol/zing bs=1M
dd: writing `/dev/vol/zing': No space left on device
3001+0 records in
3000+0 records out
3145728000 bytes (3.1 GB) copied, 32.5236 s, 96.7 MB/s

So some additional tests (copy to another file, not LVM):

root@bond:/tmp/zing-UZFgZpj1# dd if=disk0.raw of=zing.disk bs=1M
3001+0 records in
3001+0 records out
3146776576 bytes (3.1 GB) copied, 4.64961 s, 677 MB/s

root@bond:/tmp/zing-UZFgZpj1# ls -l
total 3964404
-rw-r--r-- 1 root root  458752000 2010-03-06 16:51 disk0.qcow2
-rw-r--r-- 1 root root 3146776576 2010-03-06 17:32 disk0.raw
-rw-r--r-- 1 root root 3146776576 2010-03-06 17:33 zing.disk

Again, I'm not having any problems using the LVM partition with a KVM virtual machine, but should I be worried about it? It's size is 1,048,576 bytes (exactly 1MB) smaller than the original image file. Should I be adding 1MB to the LVM partition when I create it?

root@bond:~/vmbuilder# lvremove /dev/vol/zing
Do you really want to remove active logical volume "zing"? [y/n]: y
  Logical volume "zing" successfully removed

root@bond:~/vmbuilder# lvcreate -L3001M -n zing vol
  Rounding up size to full physical extent 2.93 GB
  Logical volume "zing" created

root@bond:/tmp/zing-UZFgZpj1# dd if=disk0.raw of=/dev/vol/zing bs=1M
3001+0 records in
3001+0 records out
3146776576 bytes (3.1 GB) copied, 31.0581 s, 101 MB/s

Now I've created a partition that's size has been rounded up, but the copy fits in it.

What is the right process for copying qcow2 files to LVM partitions? Also, any idea why is it so much faster copying to a file than to an LVM device?

Tauren
  • 739
  • 4
  • 14
  • 24

2 Answers2

2

You may simply have an off-by-one math error:

3146776576 (size, in bytes of your .raw file)  / 1024 (kb) / 1024 (mb) == 3001MB

But you made your LV exactly 3000MB ?

There's nothing wrong with DD'ing one partition onto another. Even though your vmbuilder partition list added up to 3000, your .qcow file is a hard drive image, which includes a partition table + mbr @ the front of the disk.

Jason
  • 1,885
  • 1
  • 13
  • 12
  • @Jason: that makes sense! I wasn't thinking about the partition table and mbr. I assume 1MB is enough for this in all cases? Would it be safe to simply add 1MB to the totals in my vmbuilder.partitions file, no matter how big the partitions are or how many partitions there are? I create the LVM partition first, before I know the exact size of the raw file. – Tauren Mar 07 '10 at 22:38
  • It should be safe. I don't use the qemu-img tool often, but it looks like it also supports an 'info' option, that shows the 'virtual size' of the disk? I'm willing to bet the number you get out of qemu-img info disk0.qcow will be exactly the size you need to allocate for your LV. – Jason Mar 08 '10 at 02:45
  • I think, e.g. Debian Installer likes to put 2 MB from the start of the disk to the side. This can save you some trouble, if you use GPT and a grub partition. (Yes, grub became to big for just a few sectors.) Anyway, +-1 MB will not kill You, if You use 3000 MB already. – AdamKalisz Aug 07 '18 at 14:51
  • With LVM's default extent size of 4 MiB, your volume occupies 3004 MiB anyway and current LVM does not store the requested size 3001 MiB but only the number of extents, meaning that your volume's size *is* 3004 MiB. – Joachim Wagner Feb 24 '22 at 12:18
0

You are not accounting for the space for the partition table and for alignment of the start position of partitions. 1 MiB can be enough in some situations but more may be needed. Check the actual size of the virtual disk and ensure your new volume is at least this large. Options:

  • Run qemu-img info disk0.qcow2 and look for "virtual size".
  • If you already converted the virtual disk to raw format you can just look at the size reported by ls -l disk0.raw.
  • Add the disk to a VM, start a rescue system and check the first line in the output of fdisk -l where it reports the size of the disk.

Alignment means that the start position must be a multiple of a certain size, often 1 MiB. It can cause gaps before partitions, e.g. if the alignment is at 1 MiB and you create 4 partitions with 1002.5 MiB each, you will use 1 MiB + 3 x 0.5 MiB + 4 x 1002.5 MiB = 4012.5 MiB. To copy this disk onto LVM, you need a volume with 4016 MiB assuming the default extent size of 4 MiB.