Xen devel - Jun 2008 - Preventing corruption if filesystem is modified between ''save'' and ''restore''

Is there currently a way of preventing filesystem corruption if the
following sequence of events occurs:

1. ''xm save domain domain.chk''
2. ''xm create domain''
3. ''xm shutdown domain''
4. ''xm restore domain.chk''

?

If not, I''m thinking of trying to implement into the windows gplpv
xenvbd driver something along the lines of writing a magic hash of the
date, time, and whatever else we can fit in 512 bytes to a certain
sector, inside a file that the (usermode) service reserves for such a
purpose, on ''save''. On resume, before we let xenvbd accept
commands from
the operating system we would confirm that the magic number is still
correct.

The usermode service would blank those sectors if a normal boot
occurred, thus xenvbd would deliberately cause a crash before the
filesystem got corrupted by the os.

Any comments? I haven''t really thought it all the way through so there
may yet be some problems that cannot be resolved...

Thanks

James

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

>From a XenAPI point of view we should track the state
of the virtual machine (= ''managed domain'' !=
''domain'')
and disallow unsafe transitions*, e.g:

 xm create vm  (=> vm state ''halted'' ->
''running'')
 xm save vm vm.chk (=> vm state ''running'' ->
''suspended'')
 xm create vm (error: cannot start a vm in state ''suspended'')
 xm restore vm.chk (=> vm state ''suspended'' ->
''running'')
 xm shutdown vm (=> vm state ''running'' ->
''halted'')

We can also track which disks are attached to which ''active''
vm''s too (''active'' = { ''running'' or
''suspended''}) and ensure
no two writable references exist.

This is one of the reason managed domains were introduced.

However I''m not sure what the current state of the _code_  is :-(

cheers,

S.

* : potentially could allow a --force for explicit override.

----- Original Message ----- 
From: "James Harper" <james.harper@bendigoit.com.au>
To: <xen-devel@lists.xensource.com>
Sent: Sunday, June 29, 2008 1:31 PM
Subject: [Xen-devel] Preventing corruption if filesystem is modified 
between''save'' and ''restore''


Is there currently a way of preventing filesystem corruption if the
following sequence of events occurs:

1. ''xm save domain domain.chk''
2. ''xm create domain''
3. ''xm shutdown domain''
4. ''xm restore domain.chk''

?

If not, I''m thinking of trying to implement into the windows gplpv
xenvbd driver something along the lines of writing a magic hash of the
date, time, and whatever else we can fit in 512 bytes to a certain
sector, inside a file that the (usermode) service reserves for such a
purpose, on ''save''. On resume, before we let xenvbd accept
commands from
the operating system we would confirm that the magic number is still
correct.

The usermode service would blank those sectors if a normal boot
occurred, thus xenvbd would deliberately cause a crash before the
filesystem got corrupted by the os.

Any comments? I haven''t really thought it all the way through so there
may yet be some problems that cannot be resolved...

Thanks

James

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


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

Steven Hand schreef:
> We can also track which disks are attached to which
''active''
> vm''s too (''active'' = {
''running'' or ''suspended''}) and ensure
> no two writable references exist.
Since OpenSource Xen still lives in a world where only one machine knows 
about itself I''m not really a fan of that solution ;) What if a domain 
gets started on another machine in the cluster...


Stefan

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

FWIW, I quite like your idea of checking a magic number.  The managed domains 
functionality *should* help prevent users shooting themselves in the foot on 
this but it''s not necessarily completely bullet proof in the case where
users
might be extracting the save images, backing them up somewhere, etc.

Have you looked anymore at doing this?  I wouldn''t say it''s
essential but it
is quite a neat idea.

Cheers,
Mark

On Sunday 29 June 2008, James Harper wrote:
> Is there currently a way of preventing filesystem corruption if the
> following sequence of events occurs:
>
> 1. ''xm save domain domain.chk''
> 2. ''xm create domain''
> 3. ''xm shutdown domain''
> 4. ''xm restore domain.chk''
>
> ?
>
> If not, I''m thinking of trying to implement into the windows gplpv
> xenvbd driver something along the lines of writing a magic hash of the
> date, time, and whatever else we can fit in 512 bytes to a certain
> sector, inside a file that the (usermode) service reserves for such a
> purpose, on ''save''. On resume, before we let xenvbd
accept commands from
> the operating system we would confirm that the magic number is still
> correct.
>
> The usermode service would blank those sectors if a normal boot
> occurred, thus xenvbd would deliberately cause a crash before the
> filesystem got corrupted by the os.
>
> Any comments? I haven''t really thought it all the way through so
there
> may yet be some problems that cannot be resolved...
>
> Thanks
>
> James
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel


-- 
Push Me Pull You - Distributed SCM tool (http://www.cl.cam.ac.uk/~maw48/pmpu/)

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