Re: [Xen-devel] Preventing corruption if filesystem is modified between'save' and 'restore'

["Steven Hand" <steven.hand@xxxxxxxxxxxx>]

> 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@xxxxxxxxxxxxxxxx>
To: <xen-devel@xxxxxxxxxxxxxxxxxxx>
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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel 

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