It's a reasonable question. The answer is generally reasonable, too.
"It'll take about 3 hours to set it up, then the test itself should take a few more hours. So, it'll take about a day."
There is a silent "if" at the end of that answer, though. After all, a lot could extend the time:
"... if the I can get on the hardware I need, which is currently being used by another test."
"... if the bug that blocked this test is really fixed."
"... if I don't get pulled off to another meeting between now and then."
As testers, we get used to providing information, so it's tempting to outline the ifs as well as the estimate. Most of the time, you shouldn't.
A test estimate is just an estimate. As the estimator, it's your responsibility to account for non-optimistic scenarios: all those ifs. So for each if, you get to consider how likely a problem is to occur, what you'd do if it occurred, and what that means for how long it will take you to do the test. Maybe all of those things are extremely unlikely; maybe something blows up 80% of the time (ouch!).
In either case, your estimate should now look something like: "About two days, allowing for the usual hubbub of life, plus the few hour setup time, and leaving time to run the test itself."
When you're providing an estimate, keep in mind that you need to describe the estimate, not all the things you can think of that would go wrong. Account, don't over-elaborate.