VMware Cloud Community
vminchev
Contributor
Contributor
Jump to solution

P2V converter

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?

Reply
0 Kudos
1 Solution

Accepted Solutions
patanassov
VMware Employee
VMware Employee
Jump to solution

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.

View solution in original post

Reply
0 Kudos
11 Replies
POCEH
VMware Employee
VMware Employee
Jump to solution

Could you upload log bundle? We need to check results from system info query, logged in converter-worker log.

Reply
0 Kudos
vminchev
Contributor
Contributor
Jump to solution

Yes, only IP addresses and user names are removed.  This is the full log, i tried two times to convert the machine with the same error first at 4/23/2018 11:38 AM and second at 4/23/2018 2:31 PM.

Reply
0 Kudos
patanassov
VMware Employee
VMware Employee
Jump to solution

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?

Reply
0 Kudos
vminchev
Contributor
Contributor
Jump to solution

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

Reply
0 Kudos
patanassov
VMware Employee
VMware Employee
Jump to solution

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.

Reply
0 Kudos
vminchev
Contributor
Contributor
Jump to solution

The log that is in agent task folder is only this one. But in this log i only see the error when i forgot to shrink the 2.6 TB disk. If is not this one I can look again.

Reply
0 Kudos
patanassov
VMware Employee
VMware Employee
Jump to solution

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.

Reply
0 Kudos
vminchev
Contributor
Contributor
Jump to solution

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

Reply
0 Kudos
patanassov
VMware Employee
VMware Employee
Jump to solution

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.

Reply
0 Kudos
vminchev
Contributor
Contributor
Jump to solution

This are the log in helperVM-task-1-gtvyhwsm.zip. I can not find anything else.

Reply
0 Kudos
patanassov
VMware Employee
VMware Employee
Jump to solution

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.

Reply
0 Kudos