|  |  | 
  
    |  |  | 
 
  |   |  | 
  
    |  |  | 
  
    |  |  | 
  
    |   xen-users
Re: [Xen-users] Xen 4.0 feature request 
| 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?
Thanks,
Jan
> 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
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
 | 
 |  | 
  
    |  |  |