qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 1/5] RFC: Efficient VM backup for qemu (v1)


From: Dietmar Maurer
Subject: Re: [Qemu-devel] [PATCH 1/5] RFC: Efficient VM backup for qemu (v1)
Date: Wed, 21 Nov 2012 13:25:20 +0000

> > AFAIK qcow2 file cannot store data out of order. In general, an backup
> > fd is not seekable, and we only want to do sequential writes. Image format
> always requires seekable fds?
> 
> Ah, this is what you mean by "out of order". Just out of curiosity, what are
> these non-seekable backup fds usually?

/dev/nst0 ;-)

But there are better examples. Usually you want to use some kind of
compression, and you do that with existing tools:

# backup to stdout|gzip|...

A common usage scenario is to pipe a backup into a restore (copy)

# backup to stdout|ssh to remote host -c 'restore from stdin'

It is also a performance question. Seeks are terrible slow.

> In principle even for this qcow2 could be used as an image format, however
> the existing implementation wouldn't be of much use for you, so it loses
> quite a bit of its attractiveness.
> 
> > Anyways, a qcow2 file is really complex beast - I am quite unsure if I
> > would use that for backup if it is possible.
> >
> > That would require any external tool to include >=50000 LOC
> >
> > The vma reader code is about 700 LOC (quite easy).
> 
> So what? qemu-img is already there.

Anyways, you already pointed out that the existing implementation does not work.

But I already expected such discussion. So maybe it is better we simply pipe 
all data to an external binary?
We just need to define a minimal protocol. 

In future we can produce different archivers as independent/external binaries?








reply via email to

[Prev in Thread] Current Thread [Next in Thread]