Unable to query live source machine, newest Converter, CentOS 7

[krislong]

For some reason, while using the converter software to move the shut down VM, it copies okay, but it's taking up too much space (apparently VMWare allows you to create a thin disk that is just large enough to fail when it is thickened). the VM is running CentOS 7 and is the only VM running on the host (and will be the only one running on the new host).

I'm trying to use a file-level copy using the live machine, and I get the unable to query source machine error every time.

I've unmounted everything other than /boot and / (there are two filesystems that are double-mounted, but they are unmounted), I have checked .bashrc for echo statements (there are none), I have made sure that /tmp is writable and can exec, the release file in /etc shows the correct info for the OS, and I can SSH and SCP to the machine without an issue. If you guys have any other ideas how to do this, or an alternative idea as to how I could shrink the VMDK a couple hundred gigs in order to be able to run it thick, I would appreciate it. I'll attach the log bundle.

I'm willing to entertain suggestions, would rather not have to add hardware to make this work and I've read a lot of posts on here as well as knowledgebase documents. I'm up for trying other products or other methods.

[POCEH]

About first question - you can select thin or thick disk in 'Data to copy' page of Converter UI.

About second one - your error is "2020-01-03T16:53:08.198-05:00 error vmware-converter-worker[02528] [Originator@6876 sub=Default] No disks for volume with id '/dev/pri_vg/pg_global_vol' and label '' so you don't need to unmount everithing but check LVM configuration.

HTH

[krislong]

I guess I didn't make the topic quite clear enough - the point is the reduced performance from running thin is a problem, and the host was happy to let me create an image too large to run within its diskspace, so now I can't thicken it. So I've been hoping to shrink the usage down by using the converter to shrink a filesystem that has a little extra space. I know how to copy things thin or thick, but perhaps that wasn't obvious in my post. Thanks, though.

As far as the error saying there were no disks for that volume, that's nonsense (I'm not saying it doesn't say that, I'm saying the log is wrong). See the following:

[root@MYHOST ~]# blkid /dev/pri_vg/pg_global_vol

/dev/pri_vg/pg_global_vol: UUID="115746f8-9a72-4b20-97ae-2a0786e48f76" TYPE="ext2"

it's mounted and running and has been. No idea why converter would say that, unless that message comes up for other reasons. This LVM configuration is working on hundreds of production machines, though I'm not sure I've tried to use converter to move any of them.

Thanks for replying to me. If you have any other suggestions, I'd like to know.

[POCEH]

There are too many variations of *nix configuration so it is not possible for Converter to recognize all of them properly.

I suppose in your case the problem is using UUID instead of device path /dev/sdx, because Converter looks for device paths and don't mach UUIDs to devices.

You can check is it possible to add (or change to) device path in LVM configuration and try the conversion again.

HTH