Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a KVM host machine with several VMs on it. Each VM uses a Logical Volume on the host. I need to copy the LVs to another host machine.

Normally, I would use something like:

dd if=/the/logical-volume of=/some/path/machine.dd

To turn the LV into an image file and use SCP to move it. Then use DD to copy the file back to a new LV on the new host.

The problem with this method is you need twice as much disk space as the VM takes on both machines. ie. a 5GB LV uses 5GB of space for the LV and the dd copy also uses an additional 5GB of space for the image. This is fine for small LVs, but what if (as is my case) you have a 500GB LV for a big VM? The new host machine has a 1TB hard drive, so it can't hold a 500GB dd image file and have a 500GB logical volume to copy to and have room for the host OS and room for other smaller guests.

What I would like to do is something like:

dd if=/dev/mygroup-mylv of=

In other words, copy the data directly from one logical volume to the other over the network and skip the intermediate image file.

Is this possible?

share|improve this question
up vote 14 down vote accepted

Sure, of course it's possible.

dd if=/dev/mygroup-mylv | ssh dd of=/dev/newvgroup-newlv


Do yourself a favor, though, and use something larger than the default blocksize. Maybe add bs=4M (read/write in chunks of 4 MB). You can see there's some nitpicking about blocksizes in the comments; if this is something you find yourself doing fairly often, take a little time to try it a few different times with different blocksizes and see for yourself what gets you the best transfer rates.

Answering one of the questions from the comments:

You can pipe the transfer through pv to get statistics about the transfer. It's a lot nicer than the output you get from sending signals to dd.

I will also say that while of course using netcat -- or anything else that does not impose the overhead of encryption -- is going to be more efficient, I usually find that the additional speed comes at some loss of convenience. Unless I'm moving around really large datasets, I usually stick with ssh despite the overhead because in most cases everything is already set up to Just Work.

share|improve this answer
Does the bs only affect the copy speed, or does it have an effect on how the data is stored? – Nick Feb 9 '12 at 1:29
It has no affect on how the data is stored, but it is vastly more efficient than using the default blocksize (of 512 bytes) for reading and writing. – larsks Feb 9 '12 at 1:32
@Nick: On Linux, you can send the dd process the USR1 signal to make it display a status line with the amount transferred. Get the process number of your dd process with something like ps aux | grep dd and then use this PID with the command kill -USR1 $PID. The message will be displayed on the original terminal where you started dd. – Sven Feb 9 '12 at 2:30
You probably don't want to use a bs that large since it will just block writing to the pipe to ssh until it can transfer most of it to the network socket, during which time the disk will go idle. Since the default readahead size is 128k, you probably want to stick with that. Or increase the disk readahead size. – psusi Feb 9 '12 at 3:26
@Nick: I've updated the answer re: your question above. – larsks Feb 9 '12 at 4:20

Here's an optimized version, which shows the progress using pv and uses BS for bigger chunks and also uses gzip to reduce the network traffic.

That's perfect when moving the data between slow connections like internet servers. I recommend to run the command inside a screen session. That way the ssh connection to the host from where you execute the command can be disconnected without trouble.

$ dd if=/dev/volumegroupname/logicalvolume bs=4096 | pv | gzip | \
    ssh root@ 'gzip -d | dd of=/dev/volumegroupname/logicalvolume  bs=4096'
share|improve this answer
You could use ssh -C instead of gzip. I'm not sure if there's a performance impact, but it is a lot less typing. – Samuel Edwin Ward Mar 2 '14 at 16:47
Please fix the typo: the ending quote mark must be at the very end, because bs= is an argument of dd, not ssh. – SkyRaT Mar 17 '15 at 13:36
Thanks, fixed it – Johannes Doering Mar 27 '15 at 13:27

How about using an old freind to do this. NetCat.

On the system that is losing the logical volume type

  • $ dd if=/dev/[directory]/[volume-name] | nc -l [any high number port]

Then on the receiving system. type

  • $ nc -w 10 [ip or name] [port] | dd of=/dev/[directory/[volume name]

Voila. yes some will complain that netcat is UDP. So, if your LAN has packet loss you really need to fix the LAN IMHO.

Translating, orgin box dd this file and pipe it to nc (netcat) that will listen of this port. On the receiving system, netcat will wait 10 seconds if it it gets no data before closing to [ip or name] on [port] then pipe that data to dd to write it out.

share|improve this answer
Netcat does not use UDP with these options. – Samuel Edwin Ward Mar 2 '14 at 16:46

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.