It's likely not an issue of how much free space you have, but where you have it and/or how you are trying to move it.
Is the VM composed of multiple vmdks or a single 3TB vmdk (Thin?Thick?) and what is the FTT and FTM of the Storage Policy you are trying to apply to the Object on destination vsanDatastore? How are you trying to move it, from what and what source format?
Potentially you are trying to move a -flat.vmdk and this will obviously not work past 250GB (because storing File on Object-based storage).
OK I have one vm a total of 3 tb thin provisioned being copied from a standard datastore on a vsan host to vsan on the same host.
The vm has a drive that is 1.7 TB that is the one causing the issue.
I have another vm with a 700 GB vmdk. Without issues. I thought the 255GB was a component limitation not a vmdk limitation
"I have another vm with a 700 GB vmdk. Without issues. I thought the 255GB was a component limitation not a vmdk limitation "
Yes it is the max LSOM-Component size, but it is also the max limit (well more like 230GB) that can be stored as file (as opposed to Objects) in a vSAN namespace Object - was just ruling out that you were somehow copying -flat.vmdks, if you moved a 700GB then this couldn't be the case.
What FTM and FTT Storage policy are you trying to apply to this Object on destination?
Are you trying to 'copy' the vmdk via Datastore Browser or are you using SvMotion? (or something else?)
Is it failing pre-copy or during? If during (or potentially even at pre-check) look at the clomd.log - it should give more details e.g. FDs needed:3 FDs available:2
What is the layout of this cluster? and is the available free space evenly distributed? e.g. via RVC: vsan.disks_stats <pathToCluster>
Using svmotion fails after about 5 hours all thin. Have tried 100 % reserve and 0% failures to tolarate is 1
And is it creating the vSAN Objects on destination initially and in what distribution? (again RVC will help here e.g. vsan.vm_object_info <pathToObject>)
Potentially it is placing them somewhere that there is initially enough space but then there not enough space to fully create the LSOM-Components due to growth of other data on these disks - answering my other questions should help narrow this down (+ clomd.log from when it fails).
You *could* try initially copying it as Thin and/or FTT=0 so there is less data for initial placement and then FTT=1 the data (obviously have backups before considering FTT=0).