virtualbox.org

I'm having a problem importing oracle sql developer vm:


Why it uses K: drive? It's a network share which doesn't even have space for virtual machine. I want VritualBox to install it on C: or D: drive.

These are the settings during import:


Any ideas how to fix it? Thank you in advance.

My specs:
VB: 4.3.26 r98988
OS: Windows 7 x64 SP1

It presumably uses the K:\ drive because you selected that drive in Preferences | Default Machine Folder. Like all new VMs, imported VMs will be located there.

If you want to use a different drive, you should change the preference appropriately.

The error message indicates that the unpacked VMDK was corrupted. It's possible this could be due to using a network drive, so I would test this on a local drive assuming the MD5 checksum test passes.

mpack wrote:It presumably uses the K:\ drive because you selected that drive in Preferences | Default Machine Folder. Like all new VMs, imported VMs will be located there.

If you want to use a different drive, you should change the preference appropriately.

The error message indicates that the unpacked VMDK was corrupted. It's possible this could be due to using a network drive, so I would test this on a local drive assuming the MD5 checksum test passes.

nope:


I was hoping it was maybe some environmental variable but i think i changed them all and it still uses K: drive for something.
Any other ideas?

I'll try to find/check MD5 sum (or download the vm image again)

Not having imported appliances myself, I just have a thought: Might your local PC be trying to draw then zipped archive from the network shared folder (mapped to your drive letter K, yes?) then putting the unzipped file back on the shared folder? Do you have write permissions on that shared folder? Might the network just be having glitches over all the data flowing back & forth?

Try copying the zipped archive to your local drive first and import from the local copy, if the MD5 check works out.

scottgus1 wrote:Not having imported appliances myself, I just have a thought: Might your local PC be trying to draw then zipped archive from the network shared folder (mapped to your drive letter K, yes?) then putting the unzipped file back on the shared folder? Do you have write permissions on that shared folder? Might the network just be having glitches over all the data flowing back & forth?

Try copying the zipped archive to your local drive first and import from the local copy, if the MD5 check works out.

What zipped archive, you mean *.ova file? It was in local directory (D:\download) already. If it had to uncompress it first i don't know why it had to use my network drive (K:). Yes i had write access to it, but i don't think there was enough place for it.

mpack wrote:The error message indicates that the unpacked VMDK was corrupted.

That was the exact cause, thank you. I still don't know why it displayed my K: drive in the error, but it's fixed now (i redownloaded the file from Oracle website and it worked).

Kossak wrote:If it had to uncompress it first i don't know why it had to use my network drive (K:).

Yes, files stored in OVAs have to be unpacked first. Stream VMDKs may also need to be decompressed.

If VirtualBox used your drive K then something on your system told it that it should. If not the Preferences setting then host OS temp folder path. I'm sure VirtualBox doesn't just pick a disk at random.