This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-users] Xen 4.0 feature request

To: Nathan Eisenberg <nathan@xxxxxxxxxxxxxxxx>
Subject: Re: [Xen-users] Xen 4.0 feature request
From: Jan Kalcic <jandot@xxxxxxxxxxxxxx>
Date: Tue, 07 Jul 2009 23:42:39 +0200
Cc: "xen-users@xxxxxxxxxxxxxxxxxxx" <xen-users@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 07 Jul 2009 14:40:00 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=3Dy+FO8Uv9WvJYJW9sGZpJC8uBO9aAH1yl15jDEzU3Q=; b=HT32qZ/EG8014S+pw+SRclef5fYNVfqBgu/8RTcmEFzZbmUFifpfP0FA7W96fDfLvP 5fjtdlTI6p5CyEKZypL7Re5m39p7keYR+f+ManUhnHNc5QkjlL8EPv1ASGQEHyLePYAx 09GHsU6V/VsNiyb/s+VjS/QzwnsCkT+k2knHA=
Domainkey-signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=J6p9tgsxyYkUleeRevyduyTFZonQgM/B33Emup3IbyJk0uf1SlbX077km/O+HmcZC5 1Kz4VYTP0DU8bLy0riPMGOdqy7qttQpY8iUR0RR2A5+sIf78Pm8BIllLKRqUcgYjS5gR t5veVA3VenqkFgrmJ0DGTUUDY58E34Mjj1jNo=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <11B064048F34FD4094CBA16FC04BE21960645D90@ex01>
List-help: <mailto:xen-users-request@lists.xensource.com?subject=help>
List-id: Xen user discussion <xen-users.lists.xensource.com>
List-post: <mailto:xen-users@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=unsubscribe>
References: <c31e4ce433b93e42c510b70dd1a383df@xxxxxxxxxxxx> <4A4F927C.90806@xxxxxxxxxxxxx> <cd4e9f58149e6eed7ae8064cb05c8f45@xxxxxxxxxxxx> <op.uwlnfnvhrtqp7s@xxxxxxxxx> <4A520C4C.90701@xxxxxxxxxx> <11B064048F34FD4094CBA16FC04BE21960645B38@ex01> <a06240812c677f1668fd4@xxxxxxxxxxxxxxxxxxxxxx> <11B064048F34FD4094CBA16FC04BE21960645D90@ex01>
Sender: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird (X11/20081227)
Nathan Eisenberg wrote:
> The fact of the matter is that without flushing the buffers and cache, the 
> snapshot is essentially the same as what would result if you pulled the power 
> plug (sans the messy 'memory death' results that happen in the physical world 
> in the nanoseconds after RAM loses power) -and while that's hardly ideal, 
> it's good enough for many purposes - databases and filesystems  are generally 
> robust enough to handle uncommitted transactions.
> However, there are ways to get a better snapshot.  All you need is a quick 
> script that logs in to the domU,  stops the database service, runs a sync, 
> and then generates the snapshot and starts the database service again.
Doesn't  a xm pause work it out?

> Best Regards
> Nathan Eisenberg
> Sr. Systems Administrator
> Atlas Networks, LLC
> support@xxxxxxxxxxxxxxxx
> http://support.atlasnetworks.us/portal
> -----Original Message-----
> From: xen-users-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:xen-users-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Simon Hobson
> Sent: Monday, July 06, 2009 11:26 AM
> To: xen-users@xxxxxxxxxxxxxxxxxxx
> Subject: RE: [Xen-users] Xen 4.0 feature request
> Nathan Eisenberg wrote:
>> Why can't you save only one VM with LVM snapshots?  Sounds like you 
>> have an odd implementation, rather that there being a problem with 
>> LVM.  We export two LVs per domU - 1 'data' and 1 'swap'.  I can 
>> easily snapshot the 'data' LV of any single domU without a 
>> performance problem.
> How do you deal with the fact that you are snapshotting a dirty state 
> ? Unless you are using LVM inside the DomU (in which case Xen is 
> irrelevant), then when you make a snapshot, it will NOT include any 
> dirty blocks in the guests cache.
> Unless you collaborate with the guest, get it to stop updating the 
> filesystem, and flush it's cache - then you are pretty well 
> guaranteed dirty (and probably corrupt) data.

Xen-users mailing list