Vd error verr path not found opening image

I’m having the same issue currently, and a workaround I found was to set VirtualBox’s Default Machine Folder to a subdirectory instead of just the root of the drive (i.e. «V:/VirtualBox-VMs» instead of just «V:/»).

Configuration

I installed VirtualBox 5.2.22 r126460 (Qt 5.6.2) and Vagrant 2.2.2 to their default paths on the C:/ drive on Windows 10 Pro (10.0.17763 Build 17763).

I have another SSD mounted at V: that I want to use for storing both the VAGRANT_HOME (.vagrant.d) and VirtualBox disks that Vagrant spins up.

Steps to Duplicate Issue

1. Mount a disk at the drive letter V: (or any letter other than C: really).
2. Install VirtualBox and Vagrant versions described above.
3. Open VirtualBox > File > Preferences > General and set Default Machine Folder to «V:»
4. Create a directory called «vagrant».
5. Open CMD or Git Bash in the «vagrant» directory from step 4 and run:

SETX VAGRANT_HOME "V:.vagrant.d"
vagrant init hashicorp/precise64
vagrant up

The output should look similar to this:

Bringing machine 'default' up with 'virtualbox' provider...
==> default: Importing base box 'hashicorp/precise64'...
==> default: Matching MAC address for NAT networking...
==> default: Checking if box 'hashicorp/precise64' is up to date...
==> default: Setting the name of the VM: vagrant_default_1543771906584_48004
==> default: Vagrant has detected a configuration issue which exposes a
==> default: vulnerability with the installed version of VirtualBox. The
==> default: current guest is configured to use an E1000 NIC type for a
==> default: network adapter which is vulnerable in this version of VirtualBox.
==> default: Ensure the guest is trusted to use this configuration or update
==> default: the NIC type using one of the methods below:
==> default:
==> default:   https://www.vagrantup.com/docs/virtualbox/configuration.html#default-nic-type
==> default:   https://www.vagrantup.com/docs/virtualbox/networking.html#virtualbox-nic-type
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
    default: Adapter 1: nat
==> default: Forwarding ports...
    default: 22 (guest) => 2222 (host) (adapter 1)
==> default: Booting VM...
There was an error while executing `VBoxManage`, a CLI used by Vagrant for controlling VirtualBox. The command and stderr is shown below.

Command: ["startvm", "f17cad34-b2bc-495b-9d6e-a9414257f931", "--type", "headless"]

Stderr: VBoxManage.exe: error: Could not open the medium 'V:\precise64_1543771898753_84633box-disk1.vmdk'.
VBoxManage.exe: error: VD: error VERR_PATH_NOT_FOUND opening image file 'V:\precise64_1543771898753_84633box-disk1.vmdk' (VERR_PATH_NOT_FOUND)
VBoxManage.exe: error: Details: code E_FAIL (0x80004005), component MediumWrap, interface IMedium

Observations

What’s interesting is that the actual directory that is made in V: does not match the directory listed in the VBoxManage.exe error. The directory created in V: is named something like «vagrant_default_1543771898753_35470», but the directory in the error is «precise64_1543771898753_84633».

If I rename the «vagrant_default_1543771898753_35470» directory to the path VBoxManage.exe is looking for (i.e. «precise64_1543771898753_84633»), I can run vagrant up and it’ll work.

Workaround

I ended up finding out that if you just change the Default Machine Folder to include a subdirectory, everything works.

For example, I updated my Default Machine Folder in VirtualBox to «V:/VirtualBox-VMs» and then ran vagrant up.

The directory Vagrant created within V:/VirtualBox-VMs was named «precise64[…]» during initial creation, but before it starts the VM it gets renamed to the correct folder name (ex. «vagrant_default_1543772386536_35470») and boots.

My Thoughts

My guess is that something within Vagrant’s code is preventing the initial directory it creates from being renamed when it’s at the root of a drive. I can see that VirtualBox correctly renames the VM in its GUI, but the path being provided by Vagrant to VirtualBox to load the VM doesn’t get updated properly.

Hopefully a fix for this can be found by someone much more knowledgeable with Vagrant’s source code, but for now I’m just going to stick to having my VirtualBox VMs run out of a subdirectory on my secondary drive.

I stumbled upon the same issue. Strange that it hasn’t been fixed in these two years.

Essentially, the fix is to apply the patch mention here:
https://github.com/hashicorp/vagrant/issues/8275#issuecomment-291031171

The problem — the patch refers to a code fragment in version_5_1.rb file but that code has been moved to version_5_0.rb. This means, you cannot apply the patch as is. In the future, it might change even more, and thus my instructions may become obsolete…

I was too lazy to edit the patch and learn how to apply it properly, so I ended up applying the changes one by one to the relevant files, as described in the patch. On Windows, I had to also change file permissions to give Modify permissions to computer users.

So, the steps are as follows:

1. open the path where Vagrant Ruby files were installed. For example, C:Program FilesVagrantembeddedgems2.1.2gemsvagrant-2.1.2pluginsprovidersvirtualbox

2. open subfolder action and in give Modify permissions to Users group on files import.rb and set_name.rb (permissions can be edited as usual through context menu, in Properties, tab Security, button Edit.., select Users and check the checkbox under Allow for Modify option)

3. open file import.rb and replace line

   id = env[:machine].provider.driver.import(ovf_file) do |progress|
   

   with

   id = env[:machine].provider.driver.import(ovf_file,env) do |progress|
   

   There should be just one line to replace.

4. open file set_name.rb and find def call(env) and add the following lines right under it:

         return @app.call(env)
   

5. open subfolder driver and in give Modify permissions to Users group on file version_5_0.rb

6. open file version_5_0.rb and replace line

   def import(ovf)
   

   with

   def import(ovf,env)
   

7. in the same file version_5_0.rb replace line

   specified_name = "#{suggested_name}_#{(Time.now.to_f * 1000.0).to_i}_#{rand(100000)}"
   

   with the following fragment

     name = env[:machine].provider_config.name
     # If no name was manually set, then use a default
     if !name
       prefix = "#{env[:root_path].basename.to_s}_#{env[:machine].name}"
       prefix.gsub!(/[^-a-z0-9_]/i, "")
   
       # milliseconds + random number suffix to allow for simultaneous
       # `vagrant up` of the same box in different dirs
       name = prefix + "_#{(Time.now.to_f * 1000.0).to_i}_#{rand(100000)}"
     end
   
     specified_name = "#{name}_#{(Time.now.to_f * 1000.0).to_i}_#{rand(100000)}"
   

8. find and delete the broken virtual machine and all of its files on the other disk, and also from .vagrantmachines folder where you launched vagrant up command. Then run vagrant up again.

Now the virtual machine should be created with a proper name and should work normally.

Страницы: [1]   Вниз

0 Пользователей и 1 Гость просматривают эту тему.

Страницы: [1]   Вверх

virtualbox.org

End user forums for VirtualBox

• Board index‹Guest systems‹Windows Guests
• Change font size
• Print view

• FAQ
• Login

error opening image file

error opening image file

by ryanGT » 22. Nov 2009, 07:16

/.VirtualBox to the virtual hard drive of the guest OS. I had limited the guest’s virtual hard drive to 10 gigs. Apparently that wasn’t enough and the deletion of the snapshot failed. But now I can’t open the next snap shot either. I am getting this message:

Failed to start the virtual machine XP.
Medium ‘/home/ryan/.VirtualBox/Machines/XP/Snapshots/.vdi’ is not accessible. Could not open the hard disk ‘/home/ryan/.VirtualBox/Machines/XP/Snapshots/.vdi’.
VD: error opening image file ‘/home/ryan/.VirtualBox/Machines/XP/Snapshots/.vdi’ (VERR_FILE_NOT_FOUND).

Can my guest OS be fixed so I can boot into it again, or do I need to start it from scratch?

Re: error opening image file

by MarkCranness » 22. Nov 2009, 09:59

How much free space on the host disk that contains the VDI files? Having a smaller (as configured in VirtualBox) virtual hard drive should not be a problem, but running out of host drive space while Deleting a snapshot will. (Deleting/Discarding? — which version are you using?)

Likely you need to start again, but please attach your /home/ryan/.VirtualBox/VirtualBox.xml and /home/ryan/.VirtualBox/Machines/XP/XP.xml files and there may be some chance we can suggest something (I’m thinking maybe the VDI files and snapshots are OK, but the xml files are out of sync).
(See ‘Upload attachment’ tab in the forum when you make a post)

Re: error opening image file

by ryanGT » 22. Nov 2009, 15:43

I am pretty sure I didn’t run out of physical hard drive space on the host. It is carved up into many partitions and two physical drives, but the partition containing the home directories has 18 gigs available and the one where I put the virtual hard drive has 15 gigs available.

The xml files are attached. I would appreciate your guidance.

Re: error opening image file

by ryanGT » 22. Nov 2009, 15:48

This seems relevant:

FYI, after the problem occurred, I tried reverting to the latest snapshot I made and it acted like it was working: it was able to load the guest OS and showed me my windows desktop, but the desktop was completely unresponsive. I tried making another snapshot at that point, but it doesn’t seem to have worked (when I start that one, the desktop is just a black screen the whole time).

Re: error opening image file

by MarkCranness » 23. Nov 2009, 03:04

Not much good news I’m afraid. The xml files say your snapshots and VDI files look like so:

Code: Select all Expand viewCollapse view XP.vdi = b16ac225-11c1-4dd9-b7bc-ce88085b526b (SP3 = 75545385-7842-4e38-b8c6-8b8339da3b24)
|
+-<730741dd-0d05-4447-9f37-8c54ef7fe101>.vdi (SP3_take2 = df32a5db-3bdb-4da9-98f1-ad9680a67aa3)
| |
| +-<5acba0d3-a321-456d-8537-b4960e421d8c>.vdi (Current State)
|
+-.vdi (? file and snapshot missing)
(The first part of each line/node is the VDI filename, and the part in brackets is the snapshot they are attached to.)

I presume your ‘. after the problem occurred, I tried reverting to the latest snapshot I made. ‘ snapshot was ‘SP3_take2’?

There are three disk states we can use:
1 The Current State, which doesn’t work too well, as you say.
2 SP3_take2, but if you recently reverted to that snapshot it will be similar to the current state anyway.
3 The base XP.vdi, which may or may not have parts of your original snapshot (the one you deleted) updated into it.

So the plan has to be to see what the base XP.VDI looks like.
The trick to doing that is to get a VM with that VDI attached without changing the VM so much that it needs reactivation (assuming re-activation might be an issue? Have you activated yet?)

If the Current State and snapshot SP3_take2 can be forever abandoned, these dirty instructions will leave you with a VM pointing directly to XP.vdi:

• Take a backup, if you feel you need to.
• Close all VirtualBox windows and VMs.
• Edit VirtualBox.xml, deleting the last 3 entries, so it looks like so:
  Code: Select allExpand viewCollapse view

  (Note:/> on end)

• Edit XP.xml, deleting all of the nested snapshots (everything between and including » » and including the and inside the snapshots).
  You should be left with one and one at the end which belong to the machine/Current State.
• edit XP.xml, change the at the end to look like so:
  Code: Select allExpand viewCollapse view
• edit XP.xml, at the very top, delete the » currentSnapshot=»» attribute from the section.
• Launch the VirtualBox GUI, select the VM, Settings>Hard Disks>Attachments>(Plus tool)>Select ‘XP.vdi’>OK
• Perhaps take a snapshot (not much point) and boot the VM. See what you can see.
• Good luck!

Re: error opening image file

by ryanGT » 23. Nov 2009, 15:24

So, I think I editted the xml files correctly (the second time), but it didn’t work. The first time the VirtualBox gui gave me errors when it tried to read XP.xml. The files for the final version that I got to work are attached. When I booted the XP guest, I got a black screen with a message about disk read error.

So, I am trying to start over. I didn’t delete anything though, so if you have any more things for me to try, I am open. I don’t know if I will have reactivation issues or not. We will see.

Источник

virtualbox.org

End user forums for VirtualBox

• Board index‹General‹VirtualBox on Windows Hosts
• Change font size
• Print view

• FAQ
• Login

VD: error VERR_FILE_NOT_FOUND opening image file ‘G:osgeo-live-9.5.vmdk’ (VERR_FILE_NOT_FOUND).

VD: error VERR_FILE_NOT_FOUND opening image file ‘G:osgeo-live-9.5.vmdk’ (VERR_FILE_NOT_FOUND).

by proma » 10. Jul 2017, 12:57

Hello,
I’ve been using virtualbox without any problem since today, when I’ve tried to start it, it says that there is an error to open a new session:

Could not open the medium ‘G:osgeo-live-9.5.vmdk’.
VD: error VERR_FILE_NOT_FOUND opening image file ‘G:osgeo-live-9.5.vmdk’ (VERR_FILE_NOT_FOUND).

Result code:
E_FAIL (0x80004005)
Component:
MediumWrap
Interface:
IMedium

Please, I need help.

Re: VD: error VERR_FILE_NOT_FOUND opening image file ‘G:osgeo-live-9.5.vmdk’ (VERR_FILE_NOT_FOUND).

by scottgus1 » 10. Jul 2017, 13:17

The error message, though computerish-sounding, is clear:

image file ‘G:osgeo-live-9.5.vmdk’ (VERR_ FILE_NOT_FOUND )

Does this file still exist on your computer on this path? Did it get deleted or moved?

Re: VD: error VERR_FILE_NOT_FOUND opening image file ‘G:osgeo-live-9.5.vmdk’ (VERR_FILE_NOT_FOUND).

by proma » 10. Jul 2017, 14:01

Re: VD: error VERR_FILE_NOT_FOUND opening image file ‘G:osgeo-live-9.5.vmdk’ (VERR_FILE_NOT_FOUND).

by scottgus1 » 10. Jul 2017, 14:08

Re: VD: error VERR_FILE_NOT_FOUND opening image file ‘G:osgeo-live-9.5.vmdk’ (VERR_FILE_NOT_FOUND).

by proma » 10. Jul 2017, 14:20

Re: VD: error VERR_FILE_NOT_FOUND opening image file ‘G:osgeo-live-9.5.vmdk’ (VERR_FILE_NOT_FOUND).

by scottgus1 » 10. Jul 2017, 14:23

Re: VD: error VERR_FILE_NOT_FOUND opening image file ‘G:osgeo-live-9.5.vmdk’ (VERR_FILE_NOT_FOUND).

by proma » 10. Jul 2017, 16:07

Re: VD: error VERR_FILE_NOT_FOUND opening image file ‘G:osgeo-live-9.5.vmdk’ (VERR_FILE_NOT_FOUND).

by scottgus1 » 10. Jul 2017, 16:19

Sounds like you’re up and running again! Great!

Running a guest on a removable drive is OK, if you remember a few things.

First, the external drive should be a platter drive or SSD. Flash drives, like SD cards and USB thumb drives, aren’t built to handle the constant writes a typical modern operating system does, and the drive will wear out quickly.

Second, Windows hosts fill up the drive letters for new drives from the lower end of the alphabet (C, D E etc. first. If you plug in a drive that was a certain letter before, and another drive is assigned that letter now, then the drive you plug in again will get a different letter. You may also get a different drive letter if you plug the removable drive into a different port on the computer.

If you manually pick your drive letter for removable drives at the high end of the alphabet, towards Z Y X etc., and you always plug the drive into the same port, you will stand a much better chance of not having the drive letter change.

One other thing — don’t remove the drive until after the guest is completely shut down. Computers tend to not like having their drives removed while the operating system is running.

Источник

virtualbox.org

End user forums for VirtualBox

• Board index‹General‹VirtualBox on Mac OS X Hosts
• Change font size
• Print view

• FAQ
• Login

error VERR_NOT_SUPPORTED

error VERR_NOT_SUPPORTED

by Theobrandr » 17. Dec 2015, 00:19

I am currently trying to install setup Windows XP SP1 as a guest operating system in virtualbox, however I receive this error when trying mount an iso of the install cd I have.

VD: error VERR_NOT_SUPPORTED opening image file ‘File path goes here’ (VERR_NOT_SUPPORTED).

I have tried installing through a USB CD drive and through an iso of the same CD but I receive this message.
I have also tested the cd/iso, which runs with no problem in virtualbox on a Windows 10 PC.
The latest option I have tried is creating a VHDX file of the OS installed on a computer. When attempting to use this file the same message occurs.

I am currently running the latest version of virtualbox and OS X El Capitan.

Does anyone have any idea about why this file would not work on Mac but would in Windows?

Re: error VERR_NOT_SUPPORTED

by socratis » 17. Dec 2015, 01:26

When quoting an error message it would serve us all better if you actually «quoted» the whole message accurately, not substituting parts of it, like ‘File path goes here’.

• How did you create the ISO?
• VHDX is not supported by VirtualBox.
• See Minimum information needed for assistance. As far as the VBox.log.zip goes, here’s what you do:
  • Start the VM.
  • Record the error message. EXACTLY. Post a screenshot if you have to.
  • Shut down the VM.
  • Right-click on the VM in the VirtualBox Manager.
  • Select «Show Log. «
  • Save it, ZIP it and attach it in your response.

Re: error VERR_NOT_SUPPORTED

by Theobrandr » 17. Dec 2015, 05:32

Here is the exact error message I am receiving:

Failed to open the disk image file /Volumes/Untitled/OS Files/WinXP_SP1.iso.
Could not get the storage format of the medium ‘/Volumes/Untitled/OS Files/WinXP_SP1.iso’ (VERR_NOT_SUPPORTED).
Result Code: VBOX_E_IPRT_ERROR (0x80BB0005)
Component: MediumWrap
Interface: IMedium <4afe423b-43e0-e9d0-82e8-ceb307940dda>
Callee: IVirtualBox <0169423f-46b4-cde9-91af-1e9d5b6cd945>
Callee RC: VBOX_E_OBJECT_NOT_FOUND (0x80BB0001)

I don’t have a log file to generate because this is happening during configuration, before the VM starts.
I created the iso using dd in terminal and a second time using Mac’s disk utility to image the cd. Both iso’s generate the same error message.

Re: error VERR_NOT_SUPPORTED

by socratis » 17. Dec 2015, 10:20

Then maybe there’s something wrong with «WinXP_SP1.iso»? Are you sure it is an ISO file? You could try this from the terminal:

Here’s what I get for example with one of my bootable CDs/DVDs:

BTW, what’s the filesystem of your external hard drive named «Untitled»? Is it maybe FAT? How big is the ISO supposed to be? Something does not compute. Are you sure you’re not forgetting any minor details?

Re: error VERR_NOT_SUPPORTED

by mpack » 17. Dec 2015, 11:52

Re: error VERR_NOT_SUPPORTED

by Theobrandr » 17. Dec 2015, 21:23

After many of the recommendations I began looking at the MD5’s and the the iso files that have been created in various different ways. It looks like this is an actual issue with the iso file itself. I am not sure where the issue is stemming from since I used disk utility to image the cd to and iso and used dd to do the same. I am going to take this back to square one and work on imaging a correct form of the installer cd.

Thanks for all the help everyone.

Re: error VERR_NOT_SUPPORTED

by loukingjr » 17. Dec 2015, 22:07

Re: error VERR_NOT_SUPPORTED

by Theobrandr » 17. Dec 2015, 23:55

Re: error VERR_NOT_SUPPORTED

by loukingjr » 18. Dec 2015, 00:10

Re: error VERR_NOT_SUPPORTED

by loukingjr » 18. Dec 2015, 00:46

Re: error VERR_NOT_SUPPORTED

by Theobrandr » 18. Dec 2015, 01:48

My Mac doesn’t have a CD drive, I was using an external DVD drive connected to the Mac. I tried connecting through the host with a pass through but was getting a completely different error message there.

I was able to figure out the issue, it boiled down to the iso file. For some reason using Mac Disk Utility, dd terminal, and Burn were all generating iso’s that wouldn’t load. I finally gave up, installed imgburn on a PC, a burned the cd to an iso file, and it is finally working.

Re: error VERR_NOT_SUPPORTED

by loukingjr » 18. Dec 2015, 01:52

Well, not sure what the issue was. I just installed Windows 7 directly from the install DVD and I have made a working .iso with Disk Utility from a Super Drive..

Источник

virtualbox.org

End user forums for VirtualBox

• Board index‹General‹VirtualBox on Windows Hosts
• Change font size
• Print view

• FAQ
• Login

VD: error VERR_FILE_NOT_FOUND opening image file ‘G:osgeo-live-9.5.vmdk’ (VERR_FILE_NOT_FOUND).

VD: error VERR_FILE_NOT_FOUND opening image file ‘G:osgeo-live-9.5.vmdk’ (VERR_FILE_NOT_FOUND).

by proma » 10. Jul 2017, 12:57

Hello,
I’ve been using virtualbox without any problem since today, when I’ve tried to start it, it says that there is an error to open a new session:

Could not open the medium ‘G:osgeo-live-9.5.vmdk’.
VD: error VERR_FILE_NOT_FOUND opening image file ‘G:osgeo-live-9.5.vmdk’ (VERR_FILE_NOT_FOUND).

Result code:
E_FAIL (0x80004005)
Component:
MediumWrap
Interface:
IMedium

Please, I need help.

Re: VD: error VERR_FILE_NOT_FOUND opening image file ‘G:osgeo-live-9.5.vmdk’ (VERR_FILE_NOT_FOUND).

by scottgus1 » 10. Jul 2017, 13:17

The error message, though computerish-sounding, is clear:

image file ‘G:osgeo-live-9.5.vmdk’ (VERR_ FILE_NOT_FOUND )

Does this file still exist on your computer on this path? Did it get deleted or moved?

Re: VD: error VERR_FILE_NOT_FOUND opening image file ‘G:osgeo-live-9.5.vmdk’ (VERR_FILE_NOT_FOUND).

by proma » 10. Jul 2017, 14:01

Re: VD: error VERR_FILE_NOT_FOUND opening image file ‘G:osgeo-live-9.5.vmdk’ (VERR_FILE_NOT_FOUND).

by scottgus1 » 10. Jul 2017, 14:08

Re: VD: error VERR_FILE_NOT_FOUND opening image file ‘G:osgeo-live-9.5.vmdk’ (VERR_FILE_NOT_FOUND).

by proma » 10. Jul 2017, 14:20

Re: VD: error VERR_FILE_NOT_FOUND opening image file ‘G:osgeo-live-9.5.vmdk’ (VERR_FILE_NOT_FOUND).

by scottgus1 » 10. Jul 2017, 14:23

Re: VD: error VERR_FILE_NOT_FOUND opening image file ‘G:osgeo-live-9.5.vmdk’ (VERR_FILE_NOT_FOUND).

by proma » 10. Jul 2017, 16:07

Re: VD: error VERR_FILE_NOT_FOUND opening image file ‘G:osgeo-live-9.5.vmdk’ (VERR_FILE_NOT_FOUND).

by scottgus1 » 10. Jul 2017, 16:19

Sounds like you’re up and running again! Great!

Running a guest on a removable drive is OK, if you remember a few things.

First, the external drive should be a platter drive or SSD. Flash drives, like SD cards and USB thumb drives, aren’t built to handle the constant writes a typical modern operating system does, and the drive will wear out quickly.

Second, Windows hosts fill up the drive letters for new drives from the lower end of the alphabet (C, D E etc. first. If you plug in a drive that was a certain letter before, and another drive is assigned that letter now, then the drive you plug in again will get a different letter. You may also get a different drive letter if you plug the removable drive into a different port on the computer.

If you manually pick your drive letter for removable drives at the high end of the alphabet, towards Z Y X etc., and you always plug the drive into the same port, you will stand a much better chance of not having the drive letter change.

One other thing — don’t remove the drive until after the guest is completely shut down. Computers tend to not like having their drives removed while the operating system is running.

Источник