A small caveat first, I'm aware what shibboleth is/does but haven't implemented this setup so although definable I can think of a few gotchas that might trip it up. I'd suggest taking the question to the shibboleth-users list, as that's where the users are =)
What you are trying should 'just work' as long as you can tie the auth flow to host01 or host02, this is SSO after all. If you do want to point the user back to the main domain as a "target" then there's a chance they would be bumped to the other host and re authorised for the local service provider. This should work, the process could potentially be a bit dodgy, user experience wise, if they get flipped straight away and go through a long wait for multiple redirects or they have a manual step in the IDP process to POST back to your site (i.e. No JavaSript or an IDP that doesn't track sessions well). So I think you are hitting the change mid auth.
User GET requests hostalias.com/protected
User redir to idp.com/sso?shire=host01.hostalias.com/sso&target=hostalias.com/protected
User POST to host01.hostalias.com/sso
host01.hostalias.com/sso redir to hostalias.com/protected
The gotcha may be if the shibboleth spec cares about using different domains for id/shire/target. I doubt this though.
The "clean" solution is a session manager that is able to share session state between your hosts. If you were doing the auth in a java app you could use a shared database, or a remote lookup if the local lookup failed etc. You would probably need this if your planning on scaling out horizontally with X hosts. The SP daemon has some options for sharing state this looks to be dependent on if apache would makes use of the SP for sessions.
Another option if you get stuck is to change your dns failover setup. If you map any new authenticated sessions to a host name
(host01 host02 host0n) Then you can keep a user on that host. Do auth for that host. Then only failover to a new host when it's down (or overloaded..)
This setup can present a few load balancing issue's if links to one host start being used more and might take a little management. I'd only try this if there are issues with doing the above two.
SSL Certs are based on the hostname accessed. If you have multiple host names you want to be secured for clients you probably need multiple certificates. If you have multiple subdomain host names, you may be able to get a wildcard certificate instead. For the above setup I would suggest a wildcard for publicname, host01 and host02 .HostAlias.com.
The first and third method described above would need wilcard/multiple certs to cover clients accessing the different subdomains.