Hello,
I have had some issues with certain Bluray's providing errors while trying to read. I am able to take the disk to another drive that is not being passed from the VMware host and the disc is detected by MakeMKV correctly. The error being displayed is along these lines:
Error 'Scsi error - MEDIUM ERROR:1090' Occured while reading BD-RE NECVMwar VMware IDE CDR10 1.00' at offset '<varying numbers>'
Running MakeMKV v1.7.9, I originally configured an Ubuntu Server 12.04 x64 (VNC w/ Gnome Core for GUI) to run the application. I have also attempted to pass it through to a Windows 7 x64 box. Thought here was to test Windows vs. Linux MakeMKV versions. I was originally on MakeMKV v1.7.7 until I ran into this issue with another Bluray, then I have since upgraded.
I have completed about 20 disk backups through the Linux setup, however two have failed.
I think the root of the problem lies with VMware's presentation of the BluRay drive to the Guest OS (driver?). I am running VMware ESXi v5.0.0 on whitebox, yet server class hardware. The Bluray drive is a LG BT20N connected via SATA II. The Guest OS is detecting the drive as a VMware
Has anyone else ran a similar setup or had similar issues?
MakeMKV within an VMware ESXi Guest
Re: MakeMKV within an VMware ESXi Guest
While I have not validated the solution against a known "broken" disk, I have passed the entire SATA controller through to the ESXi Guest running MakeMKV. The drive now is detected as the actual drive name instead of the VMware emulated drive.
The BluRay drive was the only SATA device connected (ESXi boot from USB, Central Storage) and it did not cause any issues with other components of the host. So far so good.
Thanks for the views!
The BluRay drive was the only SATA device connected (ESXi boot from USB, Central Storage) and it did not cause any issues with other components of the host. So far so good.
Thanks for the views!
Re: MakeMKV within an VMware ESXi Guest
Digging up my older post, but the ultimate issue was the LG drive. At the time, I had not ran enough disks to pin point the issue to the drive. VMware ESXi all along was emulating the drive as expected.