virtual clock source latency

It sounds like the 15ns is correct, it's just that you have lots of margin. (If the clock delay doesn't matter, then you have source-synchronous outputs and should constrain it that way).

If you do, just add multicycles between the internal clock and the virtual clock, i.e.:

set_multicycle_path -setup -from [get_clocks internal_clk] -to [get_clocks virtual_clk] 2

set_multicycle_path -hold -from [get_clocks internal_clk] -to [get_clocks virtual_clk] 1

A single multicycle adds ~20ns, which should take care of it.

Or is the problem on your inputs to this domain, whereby you have a hold failure? You might be doing a "same-edge transfer". This is basically where the same clock edge that launches data externally from the virtual clock goes through so much clock skew that it "beats the data" to the register, and that's the transfer you want. To do that, just add:

set_multicycle_path -setup -from [get_clocks virtual_clk] -to [get_clocks internal_clk] 0