qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC] qemu snapshot enchancement


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] [RFC] qemu snapshot enchancement
Date: Tue, 29 Jan 2013 14:16:02 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

On Mon, Jan 28, 2013 at 01:38:40PM +0000, Dietmar Maurer wrote:
> > If you've been using it for 4 years then it was without dm-thin, which is a 
> > new
> > snapshot mechanism that solves limitations of classic LVM snapshot
> > volumes.  So if you're referring to inefficient LVM snapshots then that 
> > should
> > be solvable now.
> 
> Are you sure this work on shared iSCSI devices (I have my doubts)?

If by "shared" you mean clustering support so multiple hosts can access
volumes from the same pool, then the answer is no.

If by "shared" you mean that there are iSCSI devices which are attached
to a single host at a time but the mapping can change, then that should
work fine.

> Besides, we use RHEL6.3 kernel, and AFAIK dm-thin is still not marked stable 
> there.

Yeah, it's still a fairly new feature.  The key feature is that it uses
a single storage pool which all snapshots share instead of the insane
per-snapshot volumes that need to be managed for classic LVM snapshots.

> > Or is LVM a pain for other reasons?
> 
> a.) it only works on LVM (new solution works on any storage type)
> b.) You need free space on the VG (almost every user configures LVM without 
> leaving
> any free space on the VG).
> c.) you need to specify snapshot size in advance
> d.) performance is bad on writes.
> 
> The new solution work perfectly on all storage types, works on shared 
> storage, and
> does not need any free space on the source storage.

These are good points and it sounds like QEMU-level snapshots work great
for you.

QEMU should support both our own snapshots as well as exploiting
features in lower levels of the storage stack.  That way users can
choose the best option for their use case.

Stefan



reply via email to

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