Hi all,
I'm trying to convert Linux physical machine (Ubuntu 16.04) to VM. I'm using VMware vCenter Converter Standalone 6.2.
Everything starts ok, converter starts to partitioning the destination disks, but after 1 min it says:
Error: Unable to partition the destination disks.
Status: FAILED: An error occurred during the conversion: ' /dev/root: already exists in filesystem New volume group name "root" is invalid Run `vgcreate --help' for more information. (return code 3)'.
Is the problem with the IP Helper server, that starts on the host, and maybe it has the same volume group?
Thanks for the logs,
I see now what should have caused the issue. It appears your Linux machine uses /dev/root as a link to the partition where / is mounted (should have guessed earlier).
--> /dev/root: already exists in filesystem
What you can do is rename the 'root' volume group at the source machine and then retry the conversion. Something like 'vgrename /dev/root /dev/root_1' should do.
Could you upload log bundle? We need to check results from system info query, logged in converter-worker log.
Hi,
There is something pretty strange when getting info about the logical volumes. '/dev/srv/srv' appears three times in the source machine sysinfo (while '/dev/roor/root' appears just once as expected):
<volumeGroup version="2" name="srv" capacityInBytes="2965599420416" freeSpaceInBytes="132250599424">
--> <logicalVolume name="srv" capacityInBytes="2833348820992" numberOfStripes="1">
--> <device path="/dev/srv/srv" major="252" minor="1"/>
--> </logicalVolume>
--> <logicalVolume name="srv" capacityInBytes="2833348820992" numberOfStripes="1">
--> <device path="/dev/srv/srv" major="252" minor="1"/>
--> </logicalVolume>
--> <logicalVolume name="srv" capacityInBytes="2833348820992" numberOfStripes="1">
--> <device path="/dev/srv/srv" major="252" minor="1"/>
--> </logicalVolume>
--> </volumeGroup>
--> <volumeGroup version="2" name="root" capacityInBytes="29997662208" freeSpaceInBytes="0">
--> <logicalVolume name="root" capacityInBytes="29997662208" numberOfStripes="1">
--> <device path="/dev/root/root" major="252" minor="0"/>
--> </logicalVolume>
--> </volumeGroup>
This is due to running 'lvm lvs' reporting it three times and just once for root
--> [2018-04-23 13:19:54,552 INFO storage.lvm ]: Command '/sbin/lvm vgs --units b --noheadings --unbuffered --separator \| -o vg_name,vg_size,vg_free 2>/dev/null' returned:
--> [2018-04-23 13:19:54,552 INFO storage.lvm ]: --> srv|2965599420416B|132250599424B
--> [2018-04-23 13:19:54,552 INFO storage.lvm ]: --> root|29997662208B|0B
--> [2018-04-23 13:19:54,561 INFO storage.lvm ]: Command '/sbin/lvm lvs --units b --noheadings --unbuffered --separator \| -o lv_name,vg_name,lv_size,lv_attr,stripes srv 2>/dev/null' returned:
--> [2018-04-23 13:19:54,561 INFO storage.lvm ]: --> srv|srv|2833348820992B|-wi-ao----|1
--> [2018-04-23 13:19:54,561 INFO storage.lvm ]: --> srv|srv|2833348820992B|-wi-ao----|1
--> [2018-04-23 13:19:54,561 INFO storage.lvm ]: --> srv|srv|2833348820992B|-wi-ao----|1
--> [2018-04-23 13:19:54,569 INFO storage.lvm ]: Command '/sbin/lvm lvs --units b --noheadings --unbuffered --separator \| -o lv_name,vg_name,lv_size,lv_attr,stripes root 2>/dev/null' returned:
--> [2018-04-23 13:19:54,570 INFO storage.lvm ]: --> root|root|29997662208B|-wi-ao----|1
No idea why 'lvm lvs' behaved this way. Is there anything peculiar about this volume group?
There is nothing special about the group. Just someone named it this way, when the OS was installed on the computer.
This is an output for the VG root:
--- Volume group ---
VG Name root
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 2
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 1
Open LV 1
Max PV 0
Cur PV 1
Act PV 1
VG Size 27.94 GiB
PE Size 4.00 MiB
Total PE 7152
Alloc PE / Size 7152 / 27.94 GiB
Free PE / Size 0 / 0
VG UUID MJhvf8-hjIw-khlc-w0ZT-iIcv-pR94-FZhAca
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
root root -wi-ao---- 27.94g
srv srv -wi-ao---- 2.58t
The strange thing was about 3 times having in the source /dev/srv/srv. /dev/root/root is only once.
After more careful log examination, this may not be the problem, the storage mapping shows only 1 volume for root and one for /srv at the target.
The helper log contains the invocation of vgcreate. Could you attach it too? It is part of the task log bundle, embedded in the agent task zip, which is embedded in the worker zip.
It is not the right one. In the previously posted worker log there are lines like this:
2018-04-23T14:34:02.618+03:00 info vmware-converter-worker[05576] [Originator@6876 sub=task-10] Generating helperVM task bundle for task with id="task-1".
2018-04-23T14:34:02.665+03:00 info vmware-converter-worker[05576] [Originator@6876 sub=task-10] Retrieving helper VM log bundle to "C:\Windows\TEMP\vmware-temp\vmware-SYSTEM\helperVM-task-1-gtvyhwsm.zip".
2018-04-23T14:34:02.681+03:00 info vmware-converter-worker[05576] [Originator@6876 sub=task-10] Bundle successfully retrieved to "C:\Windows\TEMP\vmware-temp\vmware-SYSTEM\helperVM-task-1-gtvyhwsm.zip".
This is what we are looking for. This zip should be inside the agent task zip. However the worker log contains 5 conversion attempts, 3 of which do not reach helper activity. These would not have helper logs in them. Look for those that have it.
By the way you, can send me the logs as private message if you feel uncomfortable to publish them.
Note: To send a private message hover the cursor over my name, a box with a 'message' button will appear.
This is the only file. I open task-5-diag-20180423113456-zhdsxm.zip, then worker-diagnostics-task-9-dei.zip and in this last zip there is a zip named agentTask-task-10-dssmmsob.zip. In agentTask-task-10-dssmmsob.zip there is the file witch i attached in the previous replay. I do not have any problem to share log files, but I can not find other file that is agent task.zip
Well, the helper log should be part of the bundle it s explicitly mentioned in the log. Perhaps it is in another task bundle?
By looking at the log and the code, such error must not happen. It looks like a bug but I have no clue as to how this could have happened.
I might suggest a workaround. Try to convert the machine by excluding the '/srv' volume to see what happens. If it is successful, add another virtual disk, (create LVM volume, format) and copy the data using e.g. scp, tar, rsync...
HTH,
Plamen
P.S.
If you happen to find the helper log, please send it to me. This is a very unusual situation. I'd like to have a look.
Thanks for the logs,
I see now what should have caused the issue. It appears your Linux machine uses /dev/root as a link to the partition where / is mounted (should have guessed earlier).
--> /dev/root: already exists in filesystem
What you can do is rename the 'root' volume group at the source machine and then retry the conversion. Something like 'vgrename /dev/root /dev/root_1' should do.