WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-users

RE: [Xen-users] Save/Restore/Reboot FS Corruption

To: "Mark Williamson" <mark.williamson@xxxxxxxxxxxx>, <xen-users@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-users] Save/Restore/Reboot FS Corruption
From: "James Harper" <james.harper@xxxxxxxxxxxxxxxx>
Date: Mon, 17 Mar 2008 13:14:19 +1100
Cc: david.corral@xxxxxxxxxxxxxxxxx
Delivery-date: Sun, 16 Mar 2008 19:15:03 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <200803150230.16901.mark.williamson@xxxxxxxxxxxx>
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/cgi-bin/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=unsubscribe>
References: <20080314111849.n5lccmy0w0g8s40w@xxxxxxxxxxxxxxxxxxxxxxxxx> <200803150230.16901.mark.williamson@xxxxxxxxxxxx>
Sender: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AciGRL5wOCPryrF2TI6IsVhpNnmUAwBju4RA
Thread-topic: [Xen-users] Save/Restore/Reboot FS Corruption
> 
> Is it possible that anything modified the domain's virtual disks
during
> the "... time passes ..." section above?  Like maybe somebody mounted
a
> filesystem in the virtual disk from dom0 for some reason?  Or if
somebody
> accidentally did an xm create in the meantime?
> 

Just thinking out loud here, but how much work do you think it would be
to stop this happening for at least lvm backed devices?

lvchange has the ability to change an lv to not-available (basically
offline), or to read-only. Assuming these changes are persistent across
reboots of Dom0, an 'xm save' could set the lv to not-available after
the save is complete, and resume could check that it is in a
not-available state before changing it back to available and starting
the domain again. That would make sure nobody has inadvertently touched
the lv in the meantime. An 'xm create' would fail because the lv was not
available, as would any attempt to mount it. 'xm create' would need to
have a 'force' option to set the lv back to available again.

For file backed devices, you could just rename the backing file on save
and rename it back again on resume.

For physical disk backed devices I don't think there is such an easy
solution...

James

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users

<Prev in Thread] Current Thread [Next in Thread>