Who Supports What?
Yes, support can be an issue. While we haven't run into that problem in supporting out ESX environment, we have run into that problem with other products that blur the support lines between groups.
For our ESX virtual machine environment, we are lucky in that our unix operations folks have taken ownership of the physical host. They are responsible for the inital creation and any host-level configuration maintenance, monitoring, etc.. For example: they are responsible for making sure the host machine is running and stable. Unless the host is grossly misconfigured (ie: having too many virtual machines that the host hardware can support), there is nothing a virtual machine can do that will affect the stability of the host.
Simply put, if there is a problem within any given guest OS, it shouldn't affect the host (that is one of the main purposes of virtualization of hardware!). Thus, it is our problem. If all the guests are having problems and nothing is misconfigured, it becomes a host issue that they (having taken ownership) need to resolve.
I understand your situation might be different. The only other advice I will try to give you is to spend some serious time talking and discussing with them outlinling any and all possible scenario's that you can think of and coming to an agreement with them on how to proceed. Get these things in writing! I cannot stress that enough. Get a document, and SLA, a commitment, etc.. etc.. whatever you want to call it that details these agreements. This should include not only the WHAT they support (hardware, software,troubleshooting roles) but also HOW and more importantly WHEN they will commit to fixing it. Granted, you can never gurantee a problem will be fixed in any certain amount of time, so what we have been doing is comitting to 1) responding to a problem by a certain time frame and 2) providing timely status updates. For excample: in a total system failure, someone is commited to respond and start working on a solution within 2 hours, regardless of time or day (24/7 support). If the system cannot be repaired within 2 hours, they shall notify the necessary parties every 2 hours with a status update. If there is a lesser fault, say, a redundant power supply fails, they will respond within 4 hours during normal business hours and commit to a resolution within 1 business day.
Once an agreement is reached, let your group sign it and get it signed by their groups.. then get your respective managers to sign and acknowledge it.
This document is your backup if or, more likely, when something goes wrong.
My final note: if something goes wrong and you know how to fix it but it is not your responsibility according the agreement to fix it - do NOT go off and fix it yourself. Go and find the one who IS responsible and work with them to fix it. It's slower.. and more frustrating but better in the long run - trust me.. I've learned this fact many times through personal experience. Oh the stories I could tell about that..
I don't know how feasible this solution is and it does make life a little more political.. how far and how formal you take this process is up to you. We have over 8000 internal users that we support in Canada and in the US spread out from coast to coast. These 8000 users are only our small division of a larger holding company that totals over 300,000 users world-wide. We are forced to do things bigger and, by nature, deal with more politics than you might...
Anyway, it's late for me and I need to go to bed. I hope I've typed my thoughts clearly.. it's about 3:00am and sometimes this late I tend to ramble..