The virtual clock about input or output in timing constrain

What do you mean by phase? If there is a clock going into the FPGA, and you constrain that clock going into it, then the delays inside the FPGA(clock insertion delays, clock latency, etc.) will be covered by timing analysis. You don't need to know this except for closing timing. For example, if your virtual clock driving an input has a 10ns period with a rise at 0, and the clock going into the FPGA is described the say, let's say there's a 3ns clock delay to the input register in the FPGA. that will be covered in the timing analysis as clock delay, will affect the clock skew, and though your setup relationship is 10ns, it will make it 3ns easier to meet setup timing and 3ns harder on hold timing.

The main time phase inside the FPGA should be known is with a PLL. For example, if that clock drives a PLL which does a 2ns phase-shift(but still keeps a 2ns clock), then your setup relationship becomes 2ns and your hold relationship becomes -8ns. There are still delays inside the FPGA that are accounted for in timing analysis, but they don't affect the setup or hold relationship.

I believe this answers your second question too.

Don't just look at your .sdc. Put something in that you think is right, launch TimeQuest, and run:

report_timing -setup -npaths 50 -detail full_path -from_clock virt_clk -panel_name "Virtual Clock||Setup"

report_timing -hold -npaths 50 -detail full_path -from_clock virt_clk -panel_name "Virtual Clock||Hold"

(If you're looking at outputs, change the -from_clock to a -to_clock" Then go in and look at the results, specifically the Waveform(which is a coarse view) and the Data Path tab(which is really where everything is at). Study how the delays are used and affect your slack. If you want, make a change to your .sdc, save it, Reset Design in TimeQuest and then re-do the reports. See how they change. I find it very useful to study the timing analysis when trying to understand how .sdc constraints affect them.