I really cannot stress enough on this. Really do not do this; you will save yourself TONS of problems.
You see I built a VM as a development VM for a project and when I was configuring SharePoint I said let me put the FQDN for the SQL server which was on the same VM. That was a single box with everything DC, DNS, SQL, SP, and VS. It went at first fairly well for normal SharePoint development. But when I dived in the heavy stuff and specially the shared applications everything went messy.
I was trying to configure the user profile application. It went good first and I was able to get the user profile service to start and then the application worked. BUT when I tried the user profile synchronization service everything went wrong. The service reported that it is starting and then after maybe 15 minutes it returns to the stopped state. I went through lots of articles about user permissions, SQL instance settings,… I tried to do everything I can from rebuilding the UPA from scratch to rebuilding the entire VM again and it did not work.
Finally as I was about to give up one of my colleges (THANK you Zsolt) asked me a very strange question (for me it is strange as it should have no effect on my problem) Did you configure the SQL of the SP using FQDN? I answered Of course!
He told me that he have seen this issue before with this type of configuration. So I un-configured SP; uninstalled it; removed all databases; then done everything again while using just the machine name and WOW it really WORKED!!!!!!!!!!!!!!!!!!!!!!!
I ended up wasting perfect 6 days of my life on this issue for no reason what so ever L One more remark; I was told also that the same issue would happen if I had used an IP address instead of the FQDN.
Conclusion: NEVER NEVER NEVER NEVER NEVER NEVER NEVER NEVER use the FQDN specially if you are installing everything on the same box (I was also told that this would not happen if I was installing on multiple boxes but I never verified that)
Just a note, if you already configured your servers using FQDN you can still solve the problem by removing all servers from the farm and adding them again one by one using the SQL server name (If you can afford that). I have not try it for multiple servers but for a single server install it worked and fixed the issue.