Expected Performance of SQL Server We have a client who has been having performance issues. One of the developers is saying that a select * from a table is taking ~50 seconds to perform the query (no joins just straight select with no fields). The table has 166 columns (I know that is probably over the top, but this is from an ERP software that the developer integrates with) and around 400,000 rows. 

Now considering the crazy number of columns and 400k records, 50 seconds seems about right for me.

The SQL Server is running on a Hyper-V VM and has decent hard drive read/write speeds, the hard-drive specs are: 16 x 600gb 15RPM 6.0Gbps SAS drives in Raid 10.

The VM performs well and has plenty of RAM, just interested to see if any experts can chime in whether they think that query is performing within reason?
It's quite a few rows, and the table is quite wide - so I'd be interested to how much data is being pulled back. You can get a good idea by capturing it in SQL Server Profiler, or from identifying the SPID, then watching the logical_reads column in sys.dm_exec_requests just before the query completes on modern versions of SQL Server. This measures 8KB pages, so divide by 128 and 1024 to get the approx size in GB. You'll probably find it's quite a chunky read like 100GB! And 100GB will always take some time to come off disc!

Following a more business approach would be having SLAs. Hopefully, it might be documented that this business action (eg "add customer") should take a maximum of 2 seconds for the system, and that business action (eg "find address") would also take 2 seconds. As long as the app is meeting or exceeding these requirements, a select * from the entire table won't matter.