Understanding *.vmdk

Hello

I have a HD in FAT format for my virtual Windows 98 Setup.

The HD (vmdk file) is set to grow when more data are added.

As the file contains FAT that I wanted to explore my own FAT content parsing code, when VMWare server does not work, to "extract files," but there are problems.

It is as if the FAT / data is corrupted?  I jumped at the offset where I found the partition table and took it from there.

I also found data inside the FAT sound structures to be 'bad', but which could arise from Windows itself is not not compatible with its own spec?

Is there more to *.vmdk I don't know?  Is it possible that there are in fact 'holes' between the parts of the data?  Do I figuered file likely to grow only at the end, maybe it's a false assumption?

Finally, is there any data available on the format I can look at?  Links? advice?  No matter what?

Your expertise is appreciated!

You will find information on the methods of correcting / supported to access files vmdk here:

http://www.VMware.com/interfaces/VMDK.html

Tags: VMware

Similar Questions

  • Need to create and add RDM disk while calling reconfigVM

    Hello

    Now I create RDM disk help createdisk method and then added the disk of the virtual machine by using the reconfigvm method using vsphere sdk in c# but I need to create and add the disk while calling the reconfigVM only. I searched and found a code as example.

    diskSpec.operation = VirtualDeviceConfigSpecOperation.add;
    diskSpec.fileOperation = VirtualDeviceConfigSpecFileOperation.create;

    ". According to my understanding, vmdk file can create while adding the LUNs as disk RDM using both add and create function, but then I try these i couldn't succeed. If anyone has tried what can you share your code or suggestions please.

    Thank you

    Vijaya

    Vijaya,

    I guess that how you specify the devicename property is invalid. You just need to assign the devicename you recovered in QueryConfigTarget to the devicename of the backup file.  Please refer below snippet for adding disk:

    Request for more information on specific devices that can be used to back up virtual devices

    CTAR ConfigTarget = cb.getConnection () .getService () .queryConfigTarget (envBrow, hostmor);

    VirtualMachineScsiDiskDeviceInfo [] arrSCSILun = (VirtualMachineScsiDiskDeviceInfo []) ctar.getScsiDisk ();

    HostScsiDisk drive;

    If (arrSCSILun! = null) {}

    for (int i = 0; i)< arrscsilun.length;="" i++)="">

    disc = arrSCSILun [i] .getDisk ();

    If (disk == null) {}

    continue;

    }

    else {}

    deviceName = arrSCSILun [i] .getDisk () .getCanonicalName ();

    }

    Add a disk
    VirtualDeviceConfigSpec diskSpec = new VirtualDeviceConfigSpec();
         
    diskSpec.setFileOperation (VirtualDeviceConfigSpecFileOperation.create);
    diskSpec.setOperation (VirtualDeviceConfigSpecOperation.add);
         
    VirtualDisk disk = new VirtualDisk();
    VirtualDiskRawDiskMappingVer1BackingInfo diskfileBacking = new VirtualDiskRawDiskMappingVer1BackingInfo();
         
    diskfileBacking.setFileName("");
    diskfileBacking.setDiskMode ("persist");
    diskfileBacking.setCompatibilityMode ("physicalMode");
       diskfileBacking.setDeviceName (deviceName); It's the devicename you got above
    System.out.println ("DeviceName assigned is" + deviceName);
    disk.setKey (new Integer(-101));
    disk.setControllerKey (new Integer (diskCtlrKey));
    disk.setUnitNumber (new Integer (0));
    disk.setBacking (diskfileBacking);
    disk.setCapacityInKB (1024);
         
    diskSpec.setDevice (disk);

    And to set the loglevel, please visit: http://kb.vmware.com/kb/1001457

  • Recover a file VMDK Snapshoted / consolidate a snapshot

    Hello

    I have a very big problem and I don't know how to deal with in the right way, I had a few old server that was set up with the weekly snapshots.

    and we have some hardware problem with the server that cause some files to capture instant adeleted the data store ccidentally.

    We can recover some of the vmdk files.

    image attached with files you can find on the server.

    We tried a few steps in order to recover the machine (change on vm vmdk configure / create a new snapshot, and delete everything in the Snapshot Manager)-I was able to turn it on with the flat vmdk, but the data is less 6 months ago.

    I found a few articles on consolidate an instant snapshot and difficulty of string but I did not really understand how to go about it.

    What should I do? Is it possible to merge these files or extract files from them?

    Capture.PNGunnamed.png

    Okay, so what I found in the files and file sizes I rebuilt an instant string possible.

    The string is: 5-> 4-> 1->->->-> db1.vmdk 6 2 14

    I had to modify two files hard (see attachment). The first fix was on no. 14 that indicated a snapshot does not exist n13. The (next) one parent that makes sense here is no. 2, so I went no. 14, no. 2. The second challenge was to change the parrentCID No. 6 to match the basic disk CID. The reason for this shift is more likely, because you have turned on on the virtual machine with db1. vmdk used as virtual virtual machine disk.

    What I recommend you do now, is to replace the two .. the VMDK (12 and 6) files with those that I have attached to this post and then clone the virtual disk from the command line by running vmkfstools-i db1 - 000005.vmdk db1 - clone.vmdk

    The next step is to attach the newly created clone as an additional virtual disk with a help of VM, or - if you want to see if the VM is able to start - fix it db1 - clone.vmdk directly on the virtual machine from db1. In the second case, please create a new snapshot before you turn the virtual machine with the cloned virtual disk. In this way that the db1 - clone.vmdk will not be changed.

    In no case be prepared there could be corruption in the file system of the client!

    André

  • Can't see VMDK copied to new/different DATASTORE - HELP!

    I tried and I tried and I tried. I found a lot of info, but not the answer I need. I don't know if I spent the next two days to research, I eventually would. So I ask forgiveness in advance if you have seen and answered present a million times before.

    REASON:

    I had an ESXI server with a data store consisting of 2 RAID 5s, consisting of a total of 6x3TB readers give me about 10 TB of space. Well, it was full. So I decided to back up all computers virtual and VMDK (in many ways, wait, it's coming) and recreate a RAID5 with all disk drives and recover 3 TB of storage. Fact. Appeared / s smart, I didn't have to buy new disks to 4 or 5 to replace them all and saved me at least $1, 000.Yeah me.

    BACKUP APPLICATION:

    I have five virtual machines running all the time, four servers, and an admin station. On the main file server, I removed non-essential readers/VMDK and started to copy them down to a NAS to spare for temporary storage. I used the VSphere Client, browsed the data store, took the VMDK files and saved off the coast. All cool with me based on the experience that I have lived this before editing the text VMDK file to rename files in the past. (Yes, I know. Easier to SSH inside and do it from the command line.) Dealing with so much data, backup and restore is literally took weeks (only on the rate of transfer of 14 Mbps at BEST and 7-8 MB/s norm.) My actual VMs and essential data I backed up with VEEAM. After everything has been saved, I recreated the new RAID and got my additional free storage. (Yes team!)

    RESTORE THE ŒUVRE IMPLEMENTATION:

    I used VEEAM to restore all my virtual machines. It worked perfectly. It's a great program. (The main file with 3.5 TB of essential data server took 90 + hours to restore!) All virtual machines are up and works fine with my essential data. Now, we start running on the problem. I used VSphere Client to browse the data store, made a new folder named READERS and started to transfer some of my VMDK removed previously stored on my NAS. I went to add some players transferred back into my VM and, SURPRISE file server! ESXi does not see them. They show by browsing the data store, but they do not have the opportunity to add to the inventory and do not lie when this database is read again. FAILED! Try to understand the things I looked at the text VMDK files and to know the difference. I was hoping that it was just a database signature/ID that needed to be updated in the current data store and everything will be edited and fixed quickly. No dice. By comparing the information, I could see the differences but had no idea of what they should be. So I created a new drive in an existing VM with the same dimensions and settings and look at all the different information in each file, and I don't see a logical solution to the problem in this way.

    Yes, I know now that I should have used a programme of SCP to copy the files. From my experience, what I did would work, but obviously my experience is limited and it did not work for this situation. I read the items similar to my situation to use the stand-alone converter, but that does not work as it is looking for a virtual machine (and thus a VMX file) convert a machine instead of by car.

    So I throw my problem to the masses more experienced than me. How can I do to re-use of my 'old' downloaded disk VMDK files in my new data store?

    INFO:

    ESXi 6.0U1

    old version of h/s disc 4

    new version of h/w discs 11

    down and 6.5 TB 3.5 to to go about 8 discs.

    Bill

    Based on http://buildvirtual.net/recreating-a-missing-vmdk-descriptor-file/, I just delete all descriptor VMDK files and recreate them using the vmkfstools. Size is just there in front of me, no problem. WHAT format of disc supported, I used, is a shoot shit. What was my mentality create these drives five years ago? Thin provisioned? Zerothick? Eagerzerothick? It turns out I did the zeroedthick all.

    So I have four hard drives, back up and functional. A fifth could be corrupt or linked to a cliché that I never knew exist and could possibly be effed. I am re-uploading now to know for sure. Three more need to be uploaded to the server and go through the process. Things are good! I am MUCH less stressed.

    The process to fix my problem ended up being this:

    • Download FILE - flat hard old files.
    • SSH server, go to the path where the files FILE - flat hard.
    • RM all the files in the FILE - flat hard to represented - flat hard.
    • ls-l see the sizes of the files represented - flat hard file
    • Use mkfstools to create new files (i.e. vmkfstools - c 137438953472 - d FILE.vmdk zeroedthick)
    • RM the new FILE - flat hard
    • MV represented - flat hard to FILE - flat hard
    • Add HDD in VSphere Client on the appropriate virtual machine.
    • Rinse and repeat.
    • Down a scotch

    Thanks to all who helped.

    I hope that this will be displayed in the search for the next fool who goes through this pain.

    -Bill

  • Need a power-Cli report which shows pools of resources, including CPU, memory, reviews, DS, VM, VMDK files in an HTML report.

    LucD

    Hi LucD,

    I'm working on a script that is basically a lot of information on the whole cloud (including several clusters). The information I need is like that

    Script creates a format of report (in HTML) of the resource pool, and each report represents a single pool that contains information of CPU, Mem, comments, warehouses of data, use the data store VMDK files and free space. We fundamentally need this information in order to understand the use of the customer as each pool represents each client.

    Could you please help me out on this then that would be great . Thank you. in advance.

    Nauman

    OK, added a line with the VMDK file name.

    $a = "$name"

    $a = $a +""

    {foreach ($cluster Get-cluster)

    foreach ($rp in Get-ResourcePool-location $cluster) {}

    $report = foreach ($vm in (Get-VM-location the $rp)) {}

    Get-disk hard - VM $vm |

    Select @{N = "Cluster"; E = {$cluster. Name}},

    @{N = "ResourcePool"; E = {$rp. Name}},

    @{N = "VM"; E = {$vm. Name}},

    @{N = 'HD'; E={$_. Name}},

    @{N = "Datastore"; E={($_. Filename.Split(']') [0]). TrimStart('[')}},

    @{N = 'Filename'; E={($_. Filename.Split('_') [1]). "Split('/') [0]}},"

    @{N = 'Path VMDK'; E={$_. File name}}.

    @{N = "Format"; E={$_. StorageFormat}},

    @{N = ' Type'; E={$_. DiskType}},

    @{N = "CapacityGB"; E={$_. CapacityGB}}

    }

    $report | ConvertTo-Html-head $a | Out-file - FilePath "C:\temp\$ (cluster$.). (Name) - $($rp.) "(Name) - report.html.

    }

    }

  • 2 TB + VMDK? How...?

    OK, maybe I'm stupid. But for the life of me, I do not understand this.

    VMware said THAT VMFS 5 supports up to 62 to VMDK.

    Yet, when I build the new data store of 14 to SAN LUN with 5.60 VMFS, max VMDK size is 2 TB due to the block size of 1 MB.

    I'm converting a file from a server 10TB server share nu metal to a virtual machine and I really don't want to use Windows dynamic disk to span multiple volumes.

    Help me understand this contradiction?

    You try this VI-client or Web client. What I remember is that only Webclient allows you to create 2 TB + VMDK. Can you check and update

  • Is a bootcamp VM faster then a virtual machine that is based vmdk?

    Performance question: is a bootcamp VM faster then a virtual machine that is based vmdk? I guess the only reason why make it faster would be to drive, reading and writing.

    Are there other benefits of performance?

    Hello

    Not a bootcamp VM is not really faster like a normal virtual machine.

    I understand your reasoning, but unless you open a lot of clichés about the virtual machine performance is almost identical or similar vmdk founded against based training camp.

    Which btw is highlighting a disadvantage of bootcamp VMs, you can not snapshots.

    Of course, if you start your VM bootcamp in native mode (and not as a virtual machine), you have a performance increase as you then run native on the material.

    --

    Wil

  • svMotion is not rename VMDK disk to the new VM?

    People,

    With 5.1 vSphere update 1

    I've renamed just a newly deployed VM of vSphere Console say oldVMName to the newVMName.

    my understanding is that, after running Storage vMotion, all the components of the virtual machine will be renamed in the newVMname, but somehow, just rename the VMFS directory only?

    svMotion front: oldVMName/oldVMName.vmdk [VMFS_vol_15]

    After svMotion: newVMName/oldVMName.vmdk [VMFS_vol_15]


    How to rename the VMDK match server display name without causing downtime?

    That's what I want to achieve:

    NewVMName/newVMName.vmdk [VMFS_vol_15]

    Yes, you will need a different Storage VMotion to rename the files.

  • Issue backup (vmdk into a vmdk)

    Explorer of Trilead for backups

    , I added a second drive me ESX whitebox. I added this drive as a 2nd disk of my VM I have Trilead on. I'm saving my VM on this drive. So a physical level this player doesn't have that a vmdk of 500 GB of the virtual machine I run backups of.

    If I lose my main data store I also lose the virtual machine data backup store came.


    Question - is this possible (and it would be easy) to enter this vmdk to a Windows system to retrieve/restore the VM 5 it contains?


    TIA!

    In order to extract the virtual machines from the disk, you must have the drivers who understand the VMFS file system. I think the best way to access the files on the VMFS volume to install ESXi on a host (you can even install ESXi on a disc/USB), connect the drive and set up the data store.

    André

  • Connection usb to esxi host and copy vmdk

    Hello

    I'm trying to migrate a vSphere cluster to another machines.  There is no network connectivity between the 2, so I intend to copy the files vmdk and vmx more via USB directly connected to the host for thoroughput max.  Anyone tried this?  I looked in the documentation and online, and I see that the only supported file systems FAT32 and ext3.  For a 40 GB virtual computer, can I use an ext3 formatted USB key, copy locally and then USB attach themselves to a host on the new cluster and copy?  Anyone see any problems with this?  We are doing this process via a USB port connected to a position of the user and SCPing between the host and the USB port on the network.  I think that cutting the transfer network will speed up the process, currently a 40-50 GB VM takes about 3 hours

    Hello

    I understand that you can read in what she argued, however...

    If there is a KB article while this does not mean that it is supported, it simply means that it is possible and you might be able to use it if the need is high enough. For example, in case of problems you can risk some stability/performance and fix the most urgent problem at hand, as a critical VM that was on a LUN which disappeared earlier that day there so that you only restore backup on a USB drive.

    Also note the supplement "additional note" at the bottom of the KB that you are facing

    Quote (my highlighting):

    More information

    The USB key must be a minimum of 4 GB in size. This procedure is not recommended for basic file transfers.

    This procedure includes steps on disabling the intercom USB host function. Then earlier in the article that they use the same feature to connect the USB drive to the guest.

    If this isn't everything, they use the DCUI for mode of tech support that their link in an article KB1017910 to using the console is already a bit dodgy on a production host. About using the console for day-to-day operations is a no No

    Another quote, this time from this KB article, underscores once again with me.

    Tech Support Mode

    Tech Support Mode (TSM) provides a command line interface that can be used by the Administrator to troubleshoot and correct abnormal conditionson hosts VMware ESXi. TSM is accessible in two ways:

    • Connecting directly to the ESXi Server console.
    • Remote SSH connection.

    Further down in this article, it is pointed out again that it is for support only, I would say is something different as 'supported environment.

    It does not mean that you can not and never use should the DCUI, but be careful.

    Back on the focus to what you're trying to do.

    If your USB drive is broken, you now have a hypervisor that attempts to mount it to the level of the hypervisor, which, in itself, can cause downtime at the level of the hypervisor risks of release for ALL your guests. USB transfer at least maintains these problems located in the virtual machine, it is attached to.

    Besides that... the only system files that you can mount is VFAT, so you can't even put files there that are larger than 2 GB (or 4 GB) in size.

    File systems ext2/ext3/ext4 that none of those who are supported, VFAT only for your external USB drive.

    Yes there are ways around the VFAT file size limit too, but you're just jumping through the next pole, and if something's not going then your users is satisfied by the retoric "but backups are faster".

    --

    Wil

  • ESXi 5.5, 5 VMFS datastore / vmdk size question

    Trying to check that I understand the vmdk for esxi 5.5 size limitation.

    If I have a VMFS 5 existing on my 5.0 esxi hosts, data store once I update my hosts to esxi 5.5 that I would then be able to have vm with vmdk is greater than 2 TB?

    I don't have to create new warehouses of data VMFS 5 after the upgrade to esxi5.5 take advanrage of the change in file size limit?

    Thanks for any help.

    That's right, at least in part. In addition to the upgrade of the host, you must also upgrade the hardware version of the virtual machine (Compatibility Mode) to take advantage of larger virtual disks (up to ~ to 62). However, always keep in mind the time needed to restore the virtual disk together where this is necessary. With 1 Gbps - assuming that you have the full available bandwidth - 2 TB will require more than 5 hours already! Then maybe organize the data in several virtual disks may be a better solution.

    André

  • Instant VMDK

    Hi everyone, I have a few questions:


    1. ESXi 5.5 can take snapshots to disk 2 TB then more? I remember reading 5.5 can take pictures up to 64 TB.
    2. If I have 2 disk on my VMware virtual machine will try to store the snapshot of the whole VM (with its 2 data warehouses)?
    3. It will make my VM performance degrades when I take snapshots of VMDK more then 2 TB.

    Really know your opinion on this. Thank you!

    1. Yes, the snapshots are possible for all sizes of virtual disks. ESXi will use for more than 2 TB of virtual disks, even if the format were rare.
    2. Not quite sure I understand the question. Anyway, with vSphere 5, snapshots of virtual disks are stored in the same folder as their virtual disk parent by default. When you create a snapshot, a snapshot will be created for each virtual disk, with the exception of the pRDMs and the independent virtual disks.
    3. Snapshots – independent of the size of the virtual disk - will always decrease performance of the virtual machine, although you can really notice this with only one or a few snapshots.

    André

  • VMDK File Naming Conventions

    Hello

    I've attached a screenshot of one of the virtual machine. I need to understand these vmdk naming conventions. Snapshot of this virtual machine was created.

    Thank you

    Mihir

    By default, the hard files have the name of the virtual machine. The first virtual disk is named hard, the second _1.vmdk of ...

    For snapshots, a 6-digit number is appended to the name (e.g. - 000001.vmdk).

    André

  • . VMDK missing but they are and fix the CID

    Hello everyone,

    I'm trying to restore a virtual machine to Vmware Workstation 8.x, from a backup, I use the same version of VMware Workstation used before (8.0.5).

    These are the files that I have in the directory:

    31/08/2012 11:16 2.147.483.648 Macbeth - 8b31b655.vmem
    25/03/2012 19:12 2.147.483.648 Macbeth - Snapshot1.vmem
    25/03/2012 19:12 40.171.327 Macbeth - Snapshot1.vmsn
    19/05/2012 23:21 37.313.493 Macbeth - Snapshot2.vmsn
    20/05/2012 18:53 2.147.483.648 Macbeth - Snapshot3.vmem
    20/05/2012 18:53 37.385.117 Macbeth - Snapshot3.vmsn
    10/02/2012 00:10 Macbeth.nvram 74.232
    25/03/2012 17:42 Macbeth.vmdk 2.386
    10/02/2012 00:10 Macbeth.vmsd 1,363
    10/02/2012 00:10 2,748 Macbeth.vmx
    23/12/2012 19:43 < DIR > Macbeth.vmx.lck
    31/08/2012 11:16 365 Macbeth.vmxf
    26/03/2012 09:18 1,213 MacbethOs
    19/05/2012 23:20 502.267.904 MacbethOs-000001 - s001.vmdk
    19/05/2012 23:20 327.680 MacbethOs-000001 - s002.vmdk
    19/05/2012 23:20 12.779.520 MacbethOs-000001 - s003.vmdk
    19/05/2012 23:20 26.542.080 MacbethOs-000001 - s004.vmdk
    19/05/2012 23:20 410.255.360 MacbethOs-000001 - s005.vmdk
    19/05/2012 23:20 1.933.443.072 MacbethOs-000001 - s006.vmdk
    19/05/2012 23:20 2.146.762.752 MacbethOs-000001 - s007.vmdk
    19/05/2012 23:20 2.133.852.160 MacbethOs-000001 - s008.vmdk
    19/05/2012 23:20 1.157.890.048 MacbethOs-000001 - s009.vmdk
    19/05/2012 23:21 327.680 MacbethOs-000001 - s010.vmdk
    19/05/2012 23:21 327.680 MacbethOs-000001 - s011.vmdk
    19/05/2012 23:21 327.680 MacbethOs-000001 - s012.vmdk
    19/05/2012 23:21 327.680 MacbethOs-000001 - s013.vmdk
    19/05/2012 23:21 327.680 MacbethOs-000001 - s014.vmdk
    19/05/2012 23:21 327.680 MacbethOs-000001 - s015.vmdk
    19/05/2012 23:21 327.680 MacbethOs-000001 - s016.vmdk
    19/05/2012 23:21 327.680 MacbethOs-000001 - s017.vmdk
    19/05/2012 23:21 327.680 MacbethOs-000001 - s018.vmdk
    19/05/2012 23:21 327.680 MacbethOs-000001 - s019.vmdk
    19/05/2012 23:21 1.114.112 MacbethOs-000001 - s020.vmdk
    19/05/2012 23:21 65,536 MacbethOs-000001 - s021.vmdk
    23/12/2012 19:02 MacbethOs - 000001.vmdk 1.265
    20/05/2012 18:52 89.980.928 MacbethOs-000002 - s001.vmdk
    20/05/2012 18:52 327.680 MacbethOs-000002 - s002.vmdk
    20/05/2012 18:52 3.932.160 MacbethOs-000002 - s003.vmdk
    20/05/2012 18:52 12.189.696 MacbethOs-000002 - s004.vmdk
    20/05/2012 18:52 35.586.048 MacbethOs-000002 - s005.vmdk
    20/05/2012 18:52 50.724.864 MacbethOs-000002 - s006.vmdk

    20/05/2012 18:52 499.908.608 MacbethOs-000002 - s007.vmdk
    20/05/2012 18:52 629.211.136 MacbethOs-000002 - s008.vmdk
    20/05/2012 18:52 720.109.568 MacbethOs-000002 - s009.vmdk
    20/05/2012 18:52 327.680 MacbethOs-000002 - s010.vmdk
    20/05/2012 18:52 327.680 MacbethOs-000002 - s011.vmdk
    20/05/2012 18:52 327.680 MacbethOs-000002 - s012.vmdk
    20/05/2012 18:52 327.680 MacbethOs-000002 - s013.vmdk
    20/05/2012 18:52 327.680 MacbethOs-000002 - s014.vmdk
    20/05/2012 18:52 327.680 MacbethOs-000002 - s016.vmdk
    20/05/2012 18:52 327.680 MacbethOs-000002 - s017.vmdk
    20/05/2012 18:52 327.680 MacbethOs-000002 - s018.vmdk
    20/05/2012 18:52 327.680 MacbethOs-000002 - s019.vmdk
    20/05/2012 18:52 327.680 MacbethOs-000002 - s020.vmdk
    20/05/2012 18:52 65,536 MacbethOs-000002 - s021.vmdk
    23/12/2012 19:02 1,277 MacbethOs - 000002.vmdk
    23/12/2012 17:01 224.133.120 MacbethOs-000003 - s001.vmdk
    23/12/2012 17:01 327.680 MacbethOs-000003 - s002.vmdk
    23/12/2012 17:01 9.830.400 MacbethOs-000003 - s003.vmdk
    23/12/2012 17:01 493.748.224 MacbethOs-000003 - s004.vmdk
    23/12/2012 17:01 694.943.744 MacbethOs-000003 - s005.vmdk
    23/12/2012 17:01 458.883.072 MacbethOs-000003 - s006.vmdk
    23/12/2012 17:01 334.168.064 MacbethOs-000003 - s007.vmdk
    23/12/2012 17:01 77.266.944 MacbethOs-000003 - s008.vmdk
    23/12/2012 17:01 1.459.814.400 MacbethOs-000003 - s009.vmdk
    23/12/2012 17:01 2.146.762.752 MacbethOs-000003 - s010.vmdk
    23/12/2012 17:01 931.069.952 MacbethOs-000003 - s011.vmdk
    23/12/2012 17:01 327.680 MacbethOs-000003 - s012.vmdk
    23/12/2012 17:01 327.680 MacbethOs-000003 - s013.vmdk
    23/12/2012 17:01 327.680 MacbethOs-000003 - s014.vmdk
    23/12/2012 17:01 327.680 MacbethOs-000003 - s015.vmdk
    23/12/2012 17:01 327.680 MacbethOs-000003 - s016.vmdk
    23/12/2012 17:01 327.680 MacbethOs-000003 - s017.vmdk
    23/12/2012 17:01 327.680 MacbethOs-000003 - s018.vmdk
    23/12/2012 17:01 327.680 MacbethOs-000003 - s019.vmdk
    23/12/2012 17:01 720.896 MacbethOs-000003 - s020.vmdk
    23/12/2012 17:01 65,536 MacbethOs-000003 - s021.vmdk
    23/12/2012 19:02 1,277 MacbethOs - 000003.vmdk
    25/03/2012 19:11 322.764.800 MacbethOs-s001
    25/03/2012 19:11 2.146.762.752 MacbethOs-s002
    25/03/2012 19:11 2.079.391.744 MacbethOs-s003
    25/03/2012 19:11 2.146.697.216 MacbethOs-s004
    25/03/2012 19:11 2.146.762.752 MacbethOs-s005
    25/03/2012 19:11 392.101.888 MacbethOs-s006
    25/03/2012 19:11 327.680 MacbethOs-s007
    25/03/2012 19:11 327.680 MacbethOs-s008
    25/03/2012 19:11 327.680 MacbethOs-s009
    25/03/2012 19:11 327.680 MacbethOs-s010
    25/03/2012 19:11 327.680 MacbethOs-s011
    25/03/2012 19:11 327.680 MacbethOs-s012
    25/03/2012 19:11 327.680 MacbethOs-p014
    25/03/2012 19:11 327.680 MacbethOs-s015
    25/03/2012 19:11 327.680 MacbethOs-s016
    25/03/2012 19:11 327.680 MacbethOs-s017
    25/03/2012 19:11 327.680 MacbethOs-s018
    25/03/2012 19:11 327.680 MacbethOs-s019
    25/03/2012 19:11 479.264.768 MacbethOs-s020
    25/03/2012 19:11 MacbethOs 131,072-s021

    Correctly, I can open the virtual machine in and find its configuration. I have a problem only with the disk receving the error message:

    The parent of this virtual disk could not be opened.

    Well, in the .vmx file I have:

    scsi0:0. Present = 'TRUE '.
    scsi0:0. FileName = "MacbethOs - 000003.vmdk".

    I have three snapshots for this virtual machine. I checked back the 3 .vdmk related descriptors and their data and CID seems appropriate. Analysis each file hard seems, I have all the files listed hard in and none of this is 0 size.

    Sorry for the post long post, I stick just to check everything to look:

    MacbethOs - 000003.vmdk:

    # Disk DescriptorFile
    version = 1
    Encoding = "windows-1252".
    CID = 74cb395a
    parentCID = e993bfa4
    isNativeSnapshot = 'no '.
    createType = "twoGbMaxExtentSparse.
    parentFileNameHint = "MacbethOs - 000002.vmdk".
    # Description of the measure
    RW SPARSE 4192256 ' MacbethOs-000003 - s001.vmdk.
    RW SPARSE 4192256 ' MacbethOs-000003 - s002.vmdk.
    RW SPARSE 4192256 ' MacbethOs-000003 - s003.vmdk.
    RW SPARSE 4192256 ' MacbethOs-000003 - s004.vmdk.
    RW SPARSE 4192256 ' MacbethOs-000003 - s005.vmdk.
    RW SPARSE 4192256 ' MacbethOs-000003 - s006.vmdk.
    RW SPARSE 4192256 ' MacbethOs-000003 - s007.vmdk.
    RW SPARSE 4192256 ' MacbethOs-000003 - s008.vmdk.
    RW SPARSE 4192256 ' MacbethOs-000003 - s009.vmdk.
    RW SPARSE 4192256 ' MacbethOs-000003 - s010.vmdk.
    RW SPARSE 4192256 ' MacbethOs-000003 - s011.vmdk.
    RW SPARSE 4192256 ' MacbethOs-000003 - s012.vmdk.
    RW SPARSE 4192256 ' MacbethOs-000003 - s013.vmdk.
    RW SPARSE 4192256 ' MacbethOs-000003 - s014.vmdk.
    RW SPARSE 4192256 ' MacbethOs-000003 - s015.vmdk.
    RW SPARSE 4192256 ' MacbethOs-000003 - s016.vmdk.
    RW SPARSE 4192256 ' MacbethOs-000003 - s017.vmdk.
    RW SPARSE 4192256 ' MacbethOs-000003 - s018.vmdk.
    RW SPARSE 4192256 ' MacbethOs-000003 - s019.vmdk.
    RW SPARSE 4192256 ' MacbethOs-000003 - s020.vmdk.
    RW SPARSE 40960 ' MacbethOs-000003 - s021.vmdk.

    # The database disk
    #DDB

    ddb.longContentID = "152e926bd42e5dba4f1181f2f7ea75ee".

    MacbethOs - 000002.vmdk:

    # Disk DescriptorFile
    version = 1
    Encoding = "windows-1252".
    CID = e993bfa4
    parentCID = 70 c 20312
    isNativeSnapshot = 'no '.
    createType = "twoGbMaxExtentSparse.
    parentFileNameHint = "MacbethOs - 000001.vmdk".
    # Description of the measure
    RW SPARSE 4192256 ' MacbethOs-000002 - s001.vmdk.
    RW SPARSE 4192256 ' MacbethOs-000002 - s002.vmdk.
    RW SPARSE 4192256 ' MacbethOs-000002 - s003.vmdk.
    RW SPARSE 4192256 ' MacbethOs-000002 - s004.vmdk.
    RW SPARSE 4192256 ' MacbethOs-000002 - s005.vmdk.
    RW SPARSE 4192256 ' MacbethOs-000002 - s006.vmdk.
    RW SPARSE 4192256 ' MacbethOs-000002 - s007.vmdk.

    RW SPARSE 4192256 ' MacbethOs-000002 - s008.vmdk.
    RW SPARSE 4192256 ' MacbethOs-000002 - s009.vmdk.
    RW SPARSE 4192256 ' MacbethOs-000002 - s010.vmdk.
    RW SPARSE 4192256 ' MacbethOs-000002 - s011.vmdk.
    RW SPARSE 4192256 ' MacbethOs-000002 - s012.vmdk.
    RW SPARSE 4192256 ' MacbethOs-000002 - s013.vmdk.
    RW SPARSE 4192256 ' MacbethOs-000002 - s014.vmdk.
    RW SPARSE 4192256 ' MacbethOs-000002 - s015.vmdk.
    RW SPARSE 4192256 ' MacbethOs-000002 - s016.vmdk.
    RW SPARSE 4192256 ' MacbethOs-000002 - s017.vmdk.
    RW SPARSE 4192256 ' MacbethOs-000002 - s018.vmdk.
    RW SPARSE 4192256 ' MacbethOs-000002 - s019.vmdk.
    RW SPARSE 4192256 ' MacbethOs-000002 - s020.vmdk.
    RW SPARSE 40960 ' MacbethOs-000002 - s021.vmdk.

    # The database disk
    #DDB

    ddb.longContentID = "152e926bd42e5dba4f1181f2f7ea75ee".

    MacbethOs - 000001.vmdk:

    # Disk DescriptorFile
    version = 1
    Encoding = "windows-1252".
    CID = 70 C 20312
    parentCID = f7ea75ee
    isNativeSnapshot = 'no '.
    createType = "twoGbMaxExtentSparse.
    parentFileNameHint = "MacbethOs".
    # Description of the measure
    RW SPARSE 4192256 ' MacbethOs-000001 - s001.vmdk.
    RW SPARSE 4192256 ' MacbethOs-000001 - s002.vmdk.
    RW SPARSE 4192256 ' MacbethOs-000001 - s003.vmdk.
    RW SPARSE 4192256 ' MacbethOs-000001 - s004.vmdk.
    RW SPARSE 4192256 ' MacbethOs-000001 - s005.vmdk.
    RW SPARSE 4192256 ' MacbethOs-000001 - s006.vmdk.
    RW SPARSE 4192256 ' MacbethOs-000001 - s007.vmdk.
    RW SPARSE 4192256 ' MacbethOs-000001 - s008.vmdk.
    RW SPARSE 4192256 ' MacbethOs-000001 - s009.vmdk.
    RW SPARSE 4192256 ' MacbethOs-000001 - s010.vmdk.
    RW SPARSE 4192256 ' MacbethOs-000001 - s011.vmdk.
    RW SPARSE 4192256 ' MacbethOs-000001 - s012.vmdk.
    RW SPARSE 4192256 ' MacbethOs-000001 - s013.vmdk.
    RW SPARSE 4192256 ' MacbethOs-000001 - s014.vmdk.
    RW SPARSE 4192256 ' MacbethOs-000001 - s015.vmdk.
    RW SPARSE 4192256 ' MacbethOs-000001 - s016.vmdk.
    RW SPARSE 4192256 ' MacbethOs-000001 - s017.vmdk.
    RW SPARSE 4192256 ' MacbethOs-000001 - s018.vmdk.
    RW SPARSE 4192256 ' MacbethOs-000001 - s019.vmdk.
    RW SPARSE 4192256 ' MacbethOs-000001 - s020.vmdk.
    RW SPARSE 40960 ' MacbethOs-000001 - s021.vmdk.


    # The database disk
    #DDB


    ddb.longContentID = "152e926bd42e5dba4f1181f2f7ea75ee".

    MacbethOs:

    # Disk DescriptorFile
    version = 1
    Encoding = "windows-1252".
    CID = f7ea75ee
    parentCID = ffffffff
    isNativeSnapshot = 'no '.
    createType = "twoGbMaxExtentSparse.


    # Description of the measure
    RW 4192256 SPARSE "MacbethOs-s001.
    RW 4192256 SPARSE "MacbethOs-s002.
    RW 4192256 SPARSE "MacbethOs-s003.
    RW 4192256 SPARSE "MacbethOs-s004.
    RW 4192256 SPARSE "MacbethOs-s005.
    RW 4192256 SPARSE "MacbethOs-s006".
    RW 4192256 SPARSE "MacbethOs-s007.
    RW 4192256 SPARSE "MacbethOs-s008.
    RW 4192256 SPARSE "MacbethOs-s009".
    RW 4192256 SPARSE "MacbethOs-s010.
    RW 4192256 SPARSE "MacbethOs-s011.
    RW 4192256 SPARSE "MacbethOs-s012.
    RW 4192256 SPARSE "MacbethOs-s013.
    RW 4192256 SPARSE "MacbethOs-p014.
    RW 4192256 SPARSE "MacbethOs-s015.
    RW 4192256 SPARSE "MacbethOs-s016.
    RW 4192256 SPARSE "MacbethOs-s017.
    RW 4192256 SPARSE "MacbethOs-s018.
    RW 4192256 SPARSE "MacbethOs-s019.
    RW 4192256 SPARSE "MacbethOs-s020.
    RW 40960 SPARSE "MacbethOs-s021.


    # The database disk
    #DDB


    ddb.virtualHWVersion = '8 '.
    ddb.longContentID = "152e926bd42e5dba4f1181f2f7ea75ee".
    DDB. UUID = "60 00 C2 98 35 e8 84 99 9 d 9 c 37 69 17 1 d f2 f8"
    DDB. Geometry.Cylinders = "5221.
    DDB. Geometry.Heads = "255".
    DDB. Geometry.sectors = "63".
    ddb.adapterType = "free".
    ddb.toolsVersion = "8449.

    I do not understand what is missing. I seem to have all the data but like I've totally lost my vm .

    Really, any help will be apreciated.

    Thank you

    Eddie

    After taking an another close look at the list of files, it looks in "MacbethOs-000002 - s015.vmdk ' is missing. The size of the other "s015" files, it seems that this file does not contain already actual data, so you could probably solve this problem by recreating the file (for example copy "MacbethOs-000002 - s014.vmdk").

    André

  • Understand the RDM?

    Hello

    I just post because I have trouble understanding the principle and operation of the RDM

    Car if I understand it, this is a mapping of a normal linked storage OUTDOOR unit a file to the local drive of the ESX VMFS?

    Question but my large, l ' unit OUTSIDE of storage Mapper en RDM must it be l ' ext3 or NTFS?

    Thanks in advance

    The file system of the RDM depand of your guest operating system disk, view what you not normal a vmdk, all of the volume of your disk file is normal view your VM and is formatted by it. This mainly allows to make under Microsoft cluster with nodes located different ESX 2 or allow the possibility of recovered data from an old server or on the contrary of "be able to participate on a physical server data."

    Eric

Maybe you are looking for