The "complete isolation" that unittest provides is excellent for unit tests (what it's designed for) but not necessarily for integration tests -- I see the attraction of reusing unittest for those, I do it myself to take advantage of special test runners &c that we have around, but, realizing that it's something of a force fit to use unittest for integration tests, I try to compensate by coding rather differently than I'd code unit tests.
When I have to spawn a server in integration testing, I tend to do the spawning at the start of the module, in a separate process -- via subprocess, or by other means appropriate to your installation, if you want to run it in a separate node or whatever -- and register with atexit the termination code that will send that server the termination request when my test-module is all finished. That's not as "cleanly separated" as unit testing would require, but I find it's good enough for integration testing, and amortizes the overhead of starting and initializing the server, which may be very high indeed, across multiple tests.
Even if you're keen to use setUp and tearDown, I still recommend using a separate process (and a separate node, if you have plenty of those lying around in a "continuous build farm" or the like). Using a different thread in the same process, as @Ned's answer suggests, strikes me as risky -- might easily produce unwanted interactions between the server and the tests, hiding some bug or causing others.
If I understand correctly you're trying to run the server not just on the same process, but even in the same thread as the tests, and that seems definitely a bad idea to me -- of course it will block everything, unless the server is coded very particularly indeed!-)