Upon googling further, I came across this link. Will have to try the steps tomorrow.
Upon googling further, I came across this link. Will have to try the steps tomorrow.
So far it seems that VM's without -ctk.vmkdk files are converted correctly. All the machines (fo far) with ctk-files are giving the permissions error at 98%.
This is very interesting case, could you upload log-budle with failed conversion?
What logs do you need? VMware-converter-worker?
Yes, the ESX logs is also valuable.
Here's the worker log. I'll check the ESX logs as well.
The exact error is:
2018-03-02T10:50:05.826+02:00 warning vmware-converter-worker[01084] [Originator@6876 sub=Default] [,0] [NFC ERROR] Nfc_GetFile: Failed to get block track file '[SAS_LUN1] New Delhi - SC1.6 Standalone\New Delhi - SC1.6 Standalone-ctk.vmdk': 11
are you log in ESX as root? is not try to log as root.
Could you explain in more details situation with CBT enablement? Your workflow for backup/restore VMs.
Converter is not compatible with CBT especially if it enforced (somehow) in destination VM.
Honestly I haven't configured anything relating to CBT. It was already enabled after I did the conversion between ESXi 4.1 and 6.5 hosts.
To me that strangest thing is that the converter worked okay with the old 4.1 environment. Same backup software (Veritas NetBackup) is used on both systems.
Edit: the destination is Workstation/Player format.
We don't test Converter with external backup/restore applications (like Veritas NetBackup), but I've found an interesting topic about permissions: How to add Virtual Machine Server credentials using tpconfig command see option 3.
Seems that access to ctk files has insufficient right or these files are locked during operation with Converter, could you verify these doubts?
Also there are few articles about enable/disable CBT VMware Knowledge Base and VMware Knowledge Base however this will interfere with NetBackup probably.
Could you test some VM by disabling CBT and do conversion?
Thanks
One of the links told me to try the sc command to see if the service is present. It appears to be, but I guess I need to see if the dependencies it depends on are an issue. This is getting beyond my technical expertise to solve on my own so I suppose I will post in the Windows support forum.
But let me ask whether you are surmising the lanmanworkstation service might be the problem or if you are sure it is the problem. I don't want to spend a lot of time solving a problem that may lead me nowhere given that for me, it is not an easy simple fix.
Thanks again for all your help.
C:\Windows\system32>sc qc lanmanworkstation
[SC] QueryServiceConfig SUCCESS
SERVICE_NAME: lanmanworkstation
TYPE : 20 WIN32_SHARE_PROCESS
START_TYPE : 2 AUTO_START
ERROR_CONTROL : 1 NORMAL
BINARY_PATH_NAME : C:\Windows\System32\svchost.exe -k NetworkService
LOAD_ORDER_GROUP : NetworkProvider
TAG : 0
DISPLAY_NAME : Workstation
DEPENDENCIES : bowser
: mrxsmb10
: nsi
SERVICE_START_NAME : NT AUTHORITY\NetworkService
Simply execute the command: "sc config lanmanworkstation depend= Bowser/MRxSmb20/NSI" (without quotes but keep spaces intact), I think your SMB1 is disabled and thus lanmanworkstation want start, with this command the SMB1 is changed with SMB2, restart after.
HTH
I tried it. It was successful.
"ChangeServiceConfig SUCCESS"
Restarted computer. But still had the same error 1068.
Hi Plamen,
my problem already solve, I give IP manual to Helper VM Configuration, because my network not using DHCP so Helper VM Network no get IP.
thank you so much for your support,
Yes, I can test it with the CBT disabled. However, the converter worked with the old ESX 4.1 environment together with the same backup software.
What about: "Seems that access to ctk files has insufficient right or these files are locked during operation with Converter, could you verify these doubts?"
I'll have to check that also. Any clue what end could lock these files? NetBackup, ESX, Converter?
Couldn't be Converter because it is one attempting to open them as part of conversion of vmdk.
V2V conversion using vCenter Standalone latest version: NIC will not regain network connectivity when powered on. The machine seems to be intact upon conversion but connectivity fails. We initially removed the NIC as it was E1000 but this is licensed pbx software, and my next step is to convert again and leave the E1000 NIC intact, except for setting the mac address for licensing reasons. 2 other machines were converted P2V and they have multiple NICs apiece. These machines took 4+ hours to convert. I haven't found any references of an issue such as this.
1. Added NIC as vmxnet3 with IPs- no connectivity
2. Re-added as E1000 with IPs - no connectivity
3. Destination is a ESXi on a Nutanix cluster. Multiple other VMs are working on this cluster and it is in production.
4. NICs are on the same network and port group as source, as they should be.
5. Destination is ESXi 5.5 using vCenter 6. Source is supposedly ESXi 5.5.
This is my first conversion but it seemed to be straightforward until this issue occurred. Has anyone run into this?
1. Should I reconvert and leave the NIC as is, albeit changing the mac?
2. Should I remove the NICs before conversion and re-add afterwards?
3. For the P2V machines (these are all Windows 2008R2 machines), should I remove the NICs before conversion? These are 500Gb sized conversions (physical disk size was 2TiB). As this are DBs, I'll have to perform these conversions again.
4. Another option would seem to be exporting the V2V as OVF though customer is reticent to do this.
Hello
First - if the converted machines boot, you don't need to re-convert. Your data have been transfered, this is purely an OS reconfiguration.issue.
What is the OS of the V2V machines? If it is Linux, V2V conversion does not reconfigure, you will need to do that manually (how exactly depends on the distro and version).
Also - with Converter you can only set the NIC count and eventually type. It doesn't map nics to virtual networks, this also needs to be done manually.
Basically - google for what needs to be done for a specific OS as if a new NIC has been added.
HTH,
Plamen