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
| 
Home