Has anyone been able to successfully P2v in 2003 r2 sever in 6.7 environment?
What tools version did you use?
What is the best strategy to get it done without problems?
↧
P2v 2003 r2 server on 6.7
↧
Re: Linux P2V Failed at 98% Converter 6.1
According to the error it is " /sbin/mkinitrd". You can always find it with "which mkinitrd".
There should be some loop in it that parses the arguments, something similar to
while [ $# -gt 0 ]; do
...
case $1 in -v |
--verbose)
...
Add an empty condition to 'swallow' '-t', e.g:
-t) ;;
↧
↧
Re: How to specify the library ( /lib ) path vCenter Converter Standalone uses to convert a Linux machine
First - Converter does not officially support Debian. If the target machines boots fine, then the conversion has been successful. The easiest thing is to leave it as is. If you want to go deeper, keep reading.
As mentioned, Converter does not support Debian. It attempts to treat it as Ubuntu and run 'initramfs' during reconfiguration. In this case it seems that it didn't recognize it correctly and has tried to run a generic (old RedHat base) mkinitrd script that issued those errors. Identifying the source as Debian is done by parsing the '/etc/debian_version' file for the version. Upload the logs (worker and helper) and check for that file on the source. If it exists - post its content, if not - try to create one with appropriate content ("<major>.<minor>" should be enough) and reconvert.
HTH,
Plamen
↧
Re: SSL Exception when Converter tries to connect to vCenter
It worked for me
↧
Slow Transfer Rate VMware Converter P2V
I am converting a physical Windows 2012 R2 server to a VM, but the transfer rate is abnormally slow, sub 50KB.
The conversion is only converting 2 drives, the boot volume (~300MB) and the C partition which is ~180GB so nothing huge. I am also not doing any resizing so it is performing a block-level clone.
I went through the VMware best practices guide for optimizing the conversion rate so SSL encryption is turned off. I set the "Data connections per task" to maximum, completely removed all AV, and made sure there were no other disk intensive tasks running during time of conversion.
The network is full Gig, and "flat" between the physical server and the VMware hosts/vCenter (one single switch).
The storage I am writing to is a Dell Compellent 8000 SAN connected via 8GB fiber channel, and the particular datastore I am writing this to is all flash.
All of this in my opinion should constitute an optimized (or at least better than average) environment for the conversion.
When I kick off the conversion it estimates ~1 hour to complete. I can watch the transfer rate initially show ~100KB, but slowly dwindle over an hour down to ~30-40KB. After about an hour the boot partition cloning shows completed, and then the estimated time remaining jumps up to 60+ DAYS. All it has left is the C partition which again is only 180GB so I'm not sure why it would be this slow and take this long.
Other factors involved:
The physical server is running SQL 2012. I am not converting any of the 8 SQL DB/Log/Temp/Backup/etc. partitions, as they are mounted via iSCSI from a SAN. My VMware environment has direct access to this SAN so my plan is to mount these drives as RDMs once the conversion is complete.
The physical server has multiple physical NICs bonded into a "team" using Microsoft's adapter teaming.
This is also not a production/critical system so any suggestions/changes etc. can be done any time. I am open to whatever.
Thanks in advance.
↧
↧
Re: Slow Transfer Rate VMware Converter P2V
Did you also stop services before starting the conversion? Also remove software not needed on the box.
↧
Re: Slow Transfer Rate VMware Converter P2V
I did not. But I'm happy to do so. When you say "all services" are we talking all running Windows services? OS related as well as 3rd party?
I did remove any unnecessary software from the server before attempting the conversion.
↧
Re: Slow Transfer Rate VMware Converter P2V
Yes, stop as much services (OS related and third party) as you can and try again.
↧
Re: Slow Transfer Rate VMware Converter P2V
Same result unfortunately. I stopped ~50% of OS related services, the ones I could stop. All SQL services. And any unnecessary third party software was removed, and the remaining third party software services were stopped.
I've gone through the Worker/Agent/Server logs, and can upload them here if you think reviewing them would help.
Worker logs shows some Errors/Warnings prior to the Clone Tasks kicking off. Here is a snippet of those:
018-10-15T08:22:24.520-04:00 warning vmware-converter-worker[03288] [Originator@6876 sub=task-2] [LiveDeviceReaderWriter] FSCTL_ALLOW_EXTENDED_DASD_IO for volume \\.\PhysicalDrive0 failed with error code 87
2018-10-15T08:22:24.520-04:00 info vmware-converter-worker[09320] [Originator@6876 sub=ThreadPool] Thread enlisted
2018-10-15T08:22:24.520-04:00 info vmware-converter-worker[06008] [Originator@6876 sub=task-2] [UsedClusterBitmapImpl] FlushFileBuffers for volume \\.\GLOBALROOT\Device\HarddiskVolumeShadowCopy3...
2018-10-15T08:22:24.520-04:00 info vmware-converter-worker[03288] [Originator@6876 sub=task-2] BlockLevelVolumeCloneMgr::CloneVolume: Using transferSize of 655360, blocksize 0 bytes, Write Cache Disabled.
-->
2018-10-15T08:22:24.520-04:00 warning vmware-converter-worker[06008] [Originator@6876 sub=task-2] [UsedClusterBitmapImpl] FlushFileBuffers failed for volume \\.\GLOBALROOT\Device\HarddiskVolumeShadowCopy3, error: 19
2018-10-15T08:22:24.520-04:00 info vmware-converter-worker[03288] [Originator@6876 sub=task-2] [StreamCacheWriter] - BlockSize 0, CapToFill 0
-->
2018-10-15T08:22:24.520-04:00 info vmware-converter-worker[03288] [Originator@6876 sub=task-2] BitmapBuilderCollection::ConsultModifiedClusterBitmap: the modified cluster bitmap will not be consulted for volume Disk#0_Partition#1
2018-10-15T08:22:24.520-04:00 info vmware-converter-worker[03288] [Originator@6876 sub=task-2] BitmapBuilderCollection::ConsultModifiedClusterBitmap: the modified cluster bitmap will not be consulted for volume Disk#0_Partition#1
2018-10-15T08:22:24.520-04:00 error vmware-converter-worker[03288] [Originator@6876 sub=task-2] BitmapBuilderCollection::ConsultUsedClusterBitmap: cannot consult the used cluster bitmap because this volume (Disk#0_Partition#1) does not support it
2018-10-15T08:22:24.520-04:00 info vmware-converter-worker[03288] [Originator@6876 sub=task-2] BitmapBuilderCollection::ConsultFileClusterBitmap: the file cluster bitmap will not be consulted for volume Disk#0_Partition#1, because the volume does not support it.
2018-10-15T08:22:24.520-04:00 error vmware-converter-worker[03288] [Originator@6876 sub=task-2] [GetVolumeSymlink] Cannot return symlink for detached volume Disk#0_Partition#1
2018-10-15T08:22:24.520-04:00 info vmware-converter-worker[05016] [Originator@6876 sub=ThreadPool] Thread enlisted
2018-10-15T08:22:24.520-04:00 error vmware-converter-worker[03288] [Originator@6876 sub=task-2] AllClusterBitmapBuilder: failed to obtain cluster size, setting the cluster size to 4096 bytes by default for volume Disk#0_Partition#1; error: Requested information is not available
2018-10-15T08:22:24.520-04:00 info vmware-converter-worker[03288] [Originator@6876 sub=task-2] GetStartingBitmapOffset: the starting bitmap offset is 0
2018-10-15T08:22:24.520-04:00 warning vmware-converter-worker[06008] [Originator@6876 sub=task-2] FileClusterBitmapBuilder [AddBadBlockExtents] Unable to get bad blocks extents for \\.\GLOBALROOT\Device\HarddiskVolumeShadowCopy3\. Error: 5
2018-10-15T08:22:24.520-04:00 info vmware-converter-worker[06008] [Originator@6876 sub=task-2] GetStartingBitmapOffset: the starting bitmap offset is 0
2018-10-15T08:22:24.536-04:00 info vmware-converter-worker[02080] [Originator@6876 sub=task-2] [UsedClusterBitmapImpl] FlushFileBuffers for volume \\.\GLOBALROOT\Device\HarddiskVolumeShadowCopy4...
2018-10-15T08:22:24.536-04:00 warning vmware-converter-worker[02080] [Originator@6876 sub=task-2] [UsedClusterBitmapImpl] FlushFileBuffers failed for volume \\.\GLOBALROOT\Device\HarddiskVolumeShadowCopy4, error: 19
2018-10-15T08:22:24.536-04:00 warning vmware-converter-worker[02080] [Originator@6876 sub=task-2] FileClusterBitmapBuilder [AddBadBlockExtents] Unable to get bad blocks extents for \\.\GLOBALROOT\Device\HarddiskVolumeShadowCopy4\. Error: 5
2018-10-15T08:22:24.536-04:00 info vmware-converter-worker[02080] [Originator@6876 sub=task-2] FileClusterBitmapBuilder::FindExtentsToSkip: Skipping file extents at 0x00000002085ac000 length 45097156608 bytes
Please let me know if anything stands out, or you would like me to upload the full log.
↧
↧
Re: Slow Transfer Rate VMware Converter P2V
The full logs are more informative (some of the errors are not error that stops the conversion).
However for slow network speed you'll need to check the path between source computer and destination ESX@902
The slow speed can be result of bad/long/throttled route path or router with low priority of your network traffic.
HTH
↧
Re: Slow Transfer Rate VMware Converter P2V
Thanks for the recommendation I will investigate network path and configuration and get back to you. In the meantime, the job log is attached.
↧
Re: Slow Transfer Rate VMware Converter P2V
I see big performance degradation: when starting "percentage: 0, xfer rate (Bps): 41119369", but then "percentage: 9, xfer rate (Bps): 75111", then "percentage: 50, xfer rate (Bps): 18533", and so on..., "percentage: 100, xfer rate (Bps): 16497" finally. Then the speed is "stabilized" for next disk around "percentage: 6, xfer rate (Bps): 39610"
If the network is not the root of the problem, then the disks and/or VSS should be.
Verify your VSS with vssadmin command - how many shadows, providers, where shadows are hold, etc. The whole conversion's consistency is based on snapshots, if snapshots are slow, then the conversion will be slow because of reading from them.
There is a (small) chance to upgrade conversion performance with <vstor2VolumesHotplug>true</vstor2VolumesHotplug> in converter-worker.xml - this option will not using big memory cache for destination disks and will load up network. (but this is a wild guess)
There is option "Data connections per task" in administration menu - you can increase the number of simultaneously transferred disks - try it (however there are limitation fro ESX side so put the value between 3 and 5)
HTH
↧
Re: Slow Transfer Rate VMware Converter P2V
I want to thank everyone for all of the input on this.
The issue ended up being network related on the Windows OS side. The server had a Heartbeat NIC attached as it was once part of a SQL AO Cluster, and for some reason (I believe because of subnet overlap) Converter was using that 10/100 NIC to perform the transfer. As soon as I disabled that NIC the conversion ran at 40MB+ and completed well within an hour.
Thanks again,
Kyle
↧
↧
Re: Windows 2000
Hi
I clieck that link,but can not go to the website,can you send a new link to me ? thans
↧
Re: Windows 2000
With SP3 only I dont think you can use Converter at all.
If I remember right even version 3.0.3 already required SP6 to do the import.
So either you update the machine to SP6 first - or you have to do the import manually.
↧
Re: Linux VM Ubuntu conversion failed at 98% grub error
HI Ivivanov, how are you?
I am now facing a pretty similar error:
FAILED: An error occurred during the conversion: 'GrubInstaller::InstallGrub: /usr/lib/vmware-converter/installGrub.sh failed with return code: 127, and message: FATAL: kernel too old Error running vmware-updateGrub.sh through chroot into /mnt/p2v-src-root Command:
chroot "/mnt/p2v-src-root" /vmware-updateGrub.sh "GRUB2" "(hd0)" "(hd0,1)" /vmware-device.map "grub2-install" '
I understand the fix mentioned then the fix is done in the source machine grub configuration or in some part in vcenter
can you please tell me were can i configure that, thanks in advance.
↧
Re: Linux VM Ubuntu conversion failed at 98% grub error
Hello zelfick,
It is a different issue you have encountered. "Kernel too old" error refers to the helper's kernel being too old for the machine you are converting (it is probably a newer, unsupported version). Unfortunately tweaking grub,cfg is not a workaround in this case.
Regards,
Plamen
↧
↧
P2V Problem "No volume found that corresponds to the volume id ..."
Hi, I have a problem with conversion of windows 2008 server to VM. I'm using VMware Converter Standalone 6.2.0 and trying to convert physical machine from another server and from source machine. always get an error below :
VolumeCloneMgr::GetVolumeInfo: No volume found that corresponds to the volume id 2-?473550000010000000000.",
--> msg = "An error occurred during the conversion: 'VolumeCloneMgr::GetVolumeInfo: No volume found that corresponds to the volume id 2-?473550000010000000000.'"
I was trying convert drives by block level, file level and thick and thin.
Logs in attachment.
Thanks for help.
↧
Re: P2V Problem "No volume found that corresponds to the volume id ..."
Hi,
Please try the resolution, as mentioned in the KB. It might help to resolve your issue:
https://kb.vmware.com/s/article/2018582?lang=en_US#q=2018582
Regards,
↧
Re: P2V Problem "No volume found that corresponds to the volume id ..."
The only one suspicious message is:
2018-10-28T01:52:01.478+02:00 warning vmware-converter-worker[04956] [Originator@6876 sub=Default] Insufficient space in datastore "EWT" to hold destination files in volumeBasedCloning mode
Seems that formatting of target volumes on VM failed somehow.
Are there some datastore policies? Converter doesn't recognize and support policies.
HTH
↧