Hello together,
I try to convert a physical Maschine into a VM with VMware vCenrter Converter 6.22.
I have created a shared folder with full access for:
everybody
(actual user name)
___VMware_conf_sa___
administrators.
The conversion starts and I can see, that the converter creates a Folder, which contains:
- VDMK-File
- VMX-File
a Folder with the Ending: .vmdk.lck
In this folder 2 Files with the name Mxxxxx.lck (xxxxx = Numbers).
So it looks at the beginning OK. But after ~30 seconds (1%) I get the message "FAILED: Unable to obtain the lock on virtual disks.".
I have googled but I can't find a helpful thread! Can somebody support me please?
Greetings
Peter
One possibility is to have the 6.2 agent remaining unchanged on the source. This may happen when converting a remote (from the point of view of converter server) machine.
If that's not the case - attach the agent and worker logs, the server's one is not very useful.
HTH,
Plamen
There is a regression with shared folder access in 6.2, as workaround use 6.1
HTH
I have now installed 6.1.1 build -3533064 - but with the same result
Here some information from the log:
2018-04-03T13:58:42.619+02:00 info vmware-converter-server[06532] [Originator@6876 sub=Default] Created new scheduler item with id = "1", firstTimeToRun = "2018-04-03 13:58:42.618", source = "", targetRPOInMinutes = "0". -- __thiscall Converter::Server::Scheduler::SchedulerItemImpl::SchedulerItemImpl(const class Converter::Server::Scheduler::SchedulerItemSpec &,const int &,const class boost::shared_ptr<class Converter::Server::Scheduler::SchedulerEnv> &,const class Vmacore::Ref<class Vmacore::Service::Logger> &,const class boost::optional<class Converter::VdbConnection &> &) ("d:/build/ob/bora-3533064/bora/sysimage/ufad/server/scheduler/schedulerItemImpl.cpp:87")
2018-04-03T13:58:42.619+02:00 info vmware-converter-server[06532] [Originator@6876 sub=Default] scheduler item with id="1" created -- int __thiscall Converter::Server::Scheduler::PriorityQScheduler::AddSchedulerItem(const class boost::shared_ptr<class Converter::Server::Scheduler::SchedulerItemSpec> &,const class boost::optional<class Converter::VdbConnection &> &) ("d:/build/ob/bora-3533064/bora/sysimage/ufad/server/scheduler/priorityQScheduler.cpp:49")
2018-04-03T13:58:42.619+02:00 info vmware-converter-server[07408] [Originator@6876 sub=Default] Scheduler scheduling item 1 to run at time = 2018-04-03 13:58:42.619. -- void __thiscall Converter::Server::Scheduler::SimpleScheduler::Run(void) ("d:/build/ob/bora-3533064/bora/sysimage/ufad/server/scheduler/simpleScheduler.cpp:109")
2018-04-03T13:58:42.650+02:00 info vmware-converter-server[08424] [Originator@6876 sub=ThreadPool] Thread enlisted
2018-04-03T13:58:42.669+02:00 info vmware-converter-server[08424] [Originator@6876 sub=Default] [task,338] [task-2] -- BEGIN -- Convert
2018-04-03T13:58:42.671+02:00 info vmware-converter-server[07416] [Originator@6876 sub=Default] Started task "task-2" for job="job-2", item ="1" -- void __thiscall Converter::Server::Job::JobProcessorImpl::StartProcessingJobs(void) ("d:/build/ob/bora-3533064/bora/sysimage/lib/converter/server/job/jobProcessorImpl.cpp:384")
2018-04-03T13:58:42.739+02:00 info vmware-converter-server[06532] [Originator@6876 sub=Default] ConverterConnection: KeepAlive timer canceled, StopKeepAlive succeeded
2018-04-03T13:58:57.555+02:00 info vmware-converter-server[08424] [Originator@6876 sub=Default] [taskSpec,618] [task-2] [TaskMap] task-2:task-1
2018-04-03T14:00:10.229+02:00 error vmware-converter-server[08424] [Originator@6876 sub=Default] [task,350] [LRO] Unexpected Exception: converter.fault.DiskLockFault
2018-04-03T14:00:10.236+02:00 info vmware-converter-server[08424] [Originator@6876 sub=Default] [task,379] [task-2] -- ERROR -- Convert: converter.fault.DiskLockFault
--> (converter.fault.DiskLockFault) {
--> faultCause = (vmodl.MethodFault) null,
--> msg = ""
--> }
One possibility is to have the 6.2 agent remaining unchanged on the source. This may happen when converting a remote (from the point of view of converter server) machine.
If that's not the case - attach the agent and worker logs, the server's one is not very useful.
HTH,
Plamen
Thanks! This was the problem! I uninstalled the converter on the source-maschine, downloaded and installed 6.1.1 and now the conversion is running! I hope without any errors, otherwise I'll come back
Greetings
Peter
Thanks to the OP for asking the right questions and VM for providing the responses and solution.
Only one question... If the latest build is broken, why it is still available for download..?
We could quip about what 'broken build' means 🙂
The current situation is that there is a regression in the latest release. The next release will have it fixed. Meanwhile 6.2 has new features that are missing from 6.1 and would be lost if removed from download.
Let me add a disclaimer though: the above is my personal opinion, not an official VMware statement.
Regards,
Plamen
Converting from a physical host to a virtual one is the basic core function of this application, and it doesn't work!! I guess you could indeed make the case that a car with blown motor but a working radio isn't completely "broken".
Sorry for the gripe, and again profound thanks for the assistance -- I am just a bit frustrated at spinning my wheels for half a day yesterday over a known issue from an RTW app.
I am sorry for your misfortune.
This won't ease the pain, but a little explanation might shed light why it is not removed from download. The core functionality comes in different variants - there are Windows and Linux sources, powered on or powered off, there are managed (vSphere) and hosted (Workstation, Player, Fusion) destinations. Converter handles a matrix of these cases, which actually work quite differently. The broken case is converting a powered on Windows machine to a hosted destination, and that only if the destination folder is accessed over a network share. Not exactly a blown engine, more like a cylinder misfiring.