-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 21 Feb 2001, (regarding Re: [plex86] Please help the newbie) Drew Northup,
N1XIM wrote:
> I don't think that anyone else has expressed interest in this idea as of yet. This
>is
> not to say that it wouldn't be a good idea. If you can figure it out, then more
>power
> to you!!!!
*grin*
Working on it... err.. (4 hours later) format is now known, look at the end.
Don't know yet if I'll do anything more with this, should have to learn C first.. ;-)
Paul - well Kylix is nice though.. maybe..
>
> Paul te Bokkel wrote:
> >BTW: did anyone investigate the VMWare disk-format to some
> >extent? It seems to be a normal image, apart from the inital lead.
> >Would be rather nice to be able to use VMWare disks... ;-)
> >Regards,
> >Paul
> >----
> >Paul te Bokkel
> >Sphere Information Technologies BV
> >PGP key available and PGP preferred
>
Analysis of VMWare virtual diskformat
=============================
(c) 2001 Paul te Bokkel, provided as is.
No warranty whatsoever ;-)
Released under GPL
I think it's not difficult to _convert_ a VMWare disk to full-sized image, but OTOH,
it
would be much nicer to have the same principle: sectors never written to will not
enlarge the diskfile. With the following information it should be possible to write at
least
a VMWare disk-import for Plex86, but IMHO it would be a "Good Thing" to implement
this format as default diskformat for Plex.
For now, my findings are this:
- - VMWare uses a three-level file-system, based upon sectors, comparable to FAT.
Start of file is a header (5 sectors) with physical config and other parameters.
- - First level: Root. Variable # entries, depending on disksize. Every entry is a
pointer to
a 2nd-level Branch, or 0 if not used.
- - Second level: Branches. Each entry is a pointer to a leafe, whose size is in the
parameters (in sectors).
- - Third level: leafes = data = the HD-sectors the VM sees and uses.
No analysis done yet about calculations how to obtain or write data. Timeformats are
unknown, and their value can change a lot within seconds, so they may be clockticks or
randoms. Only used to see if diskchecking is needed (startup, together with
inconsistent-flag) and on shutdown (backlog/set consistent). There might be a
VMWare-internal diskformat with parents and childnodes, but that is not clear. Has
anyone heard of such a thing?
Here's a Delphi listing of the header-record.
A LongWord is a UINT32
TVMBootRec = packed record
// Magic: always 'COWD' or 1146572611, stands for COWDisk (where COW is ...?)
Magic: array[0..3] of Char;
// HeaderVersion: currently 1 (build 799, version 2.0.3)
HeaderVersion,
// Flags. ?? Values other than 3 get response.
// b7..b0: b0: 1 = 'Root', 0 = child-node disk (??)
// b1: 1 = 'Check capable'. Seems to get set automatically even if 0
// b2: 1 = 'Inconsistent'. Forces check. Gets cleared on chk & fix.
// No more flags: every value above 7 gives bugreport-request.
Flags,
// TotalSectors: projected disksize / max accessible sectors by VM
TotalSectors,
// leafSectors: as from log: "Size of 3rd-level blocks: 32 sectors"
// # of sectors allocated per chunk, mostly 32 = 16k
leafSectors,
// OffsetToRoot: in sectors, 0-based. Normally 4 (= 5th sector = 0xA00)
OffsetToRoot,
// numRootEntries
// Deduced from the logs:
// "numRootEntries = 256, numSectors = 4192020, leaf = 16384"
numRootEntries,
// DiskFileSize: Size of diskfile in sectors, or, as VMWare logs it:
// "Useless offset of the next sector to allocate: x sectors"
DiskFileSize,
Cylinders,
HeadsPerCylinder: LongWord;
SectorsPerTrack: Word;
// Fill1: Blank or filled. VMWare doesn't seem to mind.
Fill1: array[ 1.. (( $420-$2A ) ] of Byte;
// ParentNodeTimeStamp: timestamp, purpose not known.
// Note: logfiles also state a ParentNodeFilename, but VMWare doesn't load
// this from any data described here.
ParentNodeTimeStamp: LongWord;
// LastModification, timestamp. "Last modification timestamp". Format not yet known
LastModification: LongWord;
// Note: from the VMWare-logs it seems here are an additional
// "Node file name" and "Node description". Purpose not known/tested.
// Shouldn't be here if Root-bit is set.
NodeFileName: array[1..60] of Char; // *should be* 0-terminated. VM doesn't check.
NodeDescription: array[1..512] of Char; // ditto
// SavedTimeStamp: "Saved modification timestamp". Format not yet known
SavedTimeStamp: LongWord;
// DriveType
DriveType: Array[0..3] of Char; // 'ide', 0 or 'scsi'
// Fill2: Blank/filled (but if 1st byte filled and drivetype = 4 chars, panic)
Fill2: array[ 1.. (( $800-$66C ) ] of Byte;
// Header ends here. The above is what's created on an empty disk,
// the data below gets added when needed (but who wants to do without
// at least 1 root and 1 branch? ;)
// These sizes are for my test-image. In reality they depend on
// numRootEntries and ?? (not leafSectors, that is used for the leaves).
// Looks like the size of a branch is hardcoded.
// RootEntries: array[ 1.. (( $A00-$800 ) div SizeOf(LongWord)) ] of LongWord;
// FirstBranch: array[ 1.. (( $1200-$A00 ) div SizeOf(LongWord)) ] of LongWord;
end;
-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.8 -- QDPGP 2.61b
iQA/AwUBOpRpWUtK1v9gXDEDEQIZ7wCbBuI2s5k4ajxBGf9LXEXQqJHJHkoAoPgo
BGc2wRqXaEcgweOvBJOvEGWb
=dGMq
-----END PGP SIGNATURE-----
----
Paul te Bokkel
Sphere Information Technologies BV
PGP key available and PGP preferred
