10:48 a.m.
Hello,
I have a virtio disk for a vm that consists of an lvm.
I would like to port this vm disk to another virtualization host that has vm
disks on file, instead.
Can I port this lvm vm-disk to file, for example with something like:
dd if=/dev/vgname/lvname of=/directory_tree/filename
and then copy "filename" to the other host and use it as a backing storage
for a vm on it?
Do I have perhaps to consider some heading for lvm metadata and skip
anything form the dd command?
Anyone already done/considered?
Thanks,
Gianluca
12:35 p.m.
ons 2010-07-28 klockan 17:48 +0200 skrev Gianluca Cecchi:
Can I port this lvm vm-disk to file, for example with something
like:
dd if=/dev/vgname/lvname of=/directory_tree/filename
Yes.
Do I have perhaps to consider some heading for lvm metadata and skip
anything form the dd command?
Nope, the LVM metadata is not visible in the LV's block device.
/Alexander
12:39 p.m.
On Wed, Jul 28, 2010 at 05:48:37PM +0200, Gianluca Cecchi wrote:
Can I port this lvm vm-disk to file, for example with something
like:
dd if=/dev/vgname/lvname of=/directory_tree/filename
and then copy "filename" to the other host and use it as a backing storage
for a vm on it?
Yes.
You can also do it in one step:
dd if=/dev/vgname/lvname bs=1024 | ssh username(a)otherserver.fqdn "dd
of=/directory_tree/filename"
You might want to add -c to the ssh cmd to compress the data if the
connection between the servers is < 100 MBit/s.
--
sven === jabber/xmpp: sven(a)lankes.net
3:41 p.m.
On Wed, Jul 28, 2010 at 07:39:30PM +0200, Sven Lankes wrote:
You might want to add -c to the ssh cmd to compress the data if the
connection between the servers is < 100 MBit/s.
When writing the original virt-p2v we found the -C option actually
makes things a lot slower, assuming the common case where you have a
gigabit network between the servers. It's quicker just to copy
without the overhead of compression.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v
11:28 a.m.
On 08/01/2010 11:41 PM, Richard W.M. Jones wrote:
On Wed, Jul 28, 2010 at 07:39:30PM +0200, Sven Lankes wrote:
> You might want to add -c to the ssh cmd to compress the data if the
> connection between the servers is< 100 MBit/s.
When writing the original virt-p2v we found the -C option actually
makes things a lot slower, assuming the common case where you have a
gigabit network between the servers. It's quicker just to copy
without the overhead of compression.
Interesting, I'd have guessed that encryption will dominate the cpu
cost, and that compression would be a win since there's less to encrypt
and transmit.
--
error compiling committee.c: too many arguments to function
2:02 p.m.
On Sun, Aug 22, 2010 at 07:28:50PM +0300, Avi Kivity wrote:
On 08/01/2010 11:41 PM, Richard W.M. Jones wrote:
>On Wed, Jul 28, 2010 at 07:39:30PM +0200, Sven Lankes wrote:
>>You might want to add -c to the ssh cmd to compress the data if the
>>connection between the servers is< 100 MBit/s.
>When writing the original virt-p2v we found the -C option actually
>makes things a lot slower, assuming the common case where you have a
>gigabit network between the servers. It's quicker just to copy
>without the overhead of compression.
Interesting, I'd have guessed that encryption will dominate the cpu
cost, and that compression would be a win since there's less to
encrypt and transmit.
Maybe my explanation is wrong too. virt-p2v was definitely much
slower when we added the '-C' option. However read on.
I just ran a test again on my local LAN. This is between two
approximately equal Fedora machines, over a moderate quality consumer
gigabit ethernet switch. The command approximates what virt-p2v does:
sending 1MB blocks from local /dev device, and at the target end using
cat to write to a file.
$ time sh -c 'dd bs=1M if=/dev/vg_trick/Windows7x64 | ssh amd "cat >
/tmp/copy1"'
16384+0 records in
16384+0 records out
17179869184 bytes (17 GB) copied, 1473.26 s, 11.7 MB/s
real 24m33.269s
user 4m16.944s
sys 4m43.181s
$ time sh -c 'dd bs=1M if=/dev/vg_trick/Windows7x64 | ssh -C amd "cat >
/tmp/copy2"'
16384+0 records in
16384+0 records out
17179869184 bytes (17 GB) copied, 1412.7 s, 12.2 MB/s
real 23m32.736s
user 17m52.739s
sys 5m0.884s
In summary:
Copy rate (no compression): 11.7 MB/s
Copy rate (with compression): 12.2 MB/s
So now compression is (slightly) faster. YMMV.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://et.redhat.com/~rjones/libguestfs/
See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html
2:31 p.m.
On 08/22/2010 10:02 PM, Richard W.M. Jones wrote:
> Interesting, I'd have guessed that encryption will dominate the cpu
> cost, and that compression would be a win since there's less to
> encrypt and transmit.
Maybe my explanation is wrong too. virt-p2v was definitely much
slower when we added the '-C' option. However read on.
I just ran a test again on my local LAN. This is between two
approximately equal Fedora machines, over a moderate quality consumer
gigabit ethernet switch. The command approximates what virt-p2v does:
sending 1MB blocks from local /dev device, and at the target end using
cat to write to a file.
$ time sh -c 'dd bs=1M if=/dev/vg_trick/Windows7x64 | ssh amd "cat>
/tmp/copy1"'
16384+0 records in
16384+0 records out
17179869184 bytes (17 GB) copied, 1473.26 s, 11.7 MB/s
real 24m33.269s
user 4m16.944s
sys 4m43.181s
11.7 MB/s = 93.6 Mb/s. Not the cpu is not loaded. Are you sure you're
using 1GbE here?
$ time sh -c 'dd bs=1M if=/dev/vg_trick/Windows7x64 | ssh -C amd
"cat> /tmp/copy2"'
16384+0 records in
16384+0 records out
17179869184 bytes (17 GB) copied, 1412.7 s, 12.2 MB/s
real 23m32.736s
user 17m52.739s
sys 5m0.884s
Suddenly you're cpu bound. So it looks like compression is really
expensive for some reason.
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
3:14 p.m.
On Sun, Aug 22, 2010 at 10:31:55PM +0300, Avi Kivity wrote:
On 08/22/2010 10:02 PM, Richard W.M. Jones wrote:
>>Interesting, I'd have guessed that encryption will dominate the cpu
>>cost, and that compression would be a win since there's less to
>>encrypt and transmit.
>Maybe my explanation is wrong too. virt-p2v was definitely much
>slower when we added the '-C' option. However read on.
>
>I just ran a test again on my local LAN. This is between two
>approximately equal Fedora machines, over a moderate quality consumer
>gigabit ethernet switch. The command approximates what virt-p2v does:
>sending 1MB blocks from local /dev device, and at the target end using
>cat to write to a file.
>
>$ time sh -c 'dd bs=1M if=/dev/vg_trick/Windows7x64 | ssh amd "cat>
/tmp/copy1"'
>16384+0 records in
>16384+0 records out
>17179869184 bytes (17 GB) copied, 1473.26 s, 11.7 MB/s
>
>real 24m33.269s
>user 4m16.944s
>sys 4m43.181s
11.7 MB/s = 93.6 Mb/s. Not the cpu is not loaded. Are you sure
you're using 1GbE here?
You're absolutely right -- I forget that it's a fast ethernet switch :-)
>$ time sh -c 'dd bs=1M if=/dev/vg_trick/Windows7x64 | ssh -C
amd "cat> /tmp/copy2"'
>16384+0 records in
>16384+0 records out
>17179869184 bytes (17 GB) copied, 1412.7 s, 12.2 MB/s
>
>real 23m32.736s
>user 17m52.739s
>sys 5m0.884s
>
Suddenly you're cpu bound. So it looks like compression is really
expensive for some reason.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
New in Fedora 11: Fedora Windows cross-compiler. Compile Windows
programs, test, and build Windows installers. Over 70 libraries supprt'd
http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw
5:31 p.m.
On Aug 22, 2010, at 12:02, "Richard W.M. Jones" <rjones(a)redhat.com>
wrote:
Doing gzip in a separate process in the "pipeline" rather than with -C you will
have separate CPUs doing compression and encryption.
--
http://askask.com/
4998
days inactive
5023
days old
8 comments
6 participants
participants (6)
-
Alexander Boström -
Ask Bjørn Hansen -
Avi Kivity -
Gianluca Cecchi -
Richard W.M. Jones -
Sven Lankes