Well, I have Spice working perfectly fine in a Windows install. However, seeing as that's not pertinent to the Linux side of things I went ahead and installed Ubuntu 14.04 in Qemu and, as expected, everything worked. I didn't bother with the git sources in this install, because I was 99% sure it was going to work anyway. I don't have a Fedora ISO lying around to test it with, but I imagine that the results would be the same. However, I don't think that even this is pertinent to the problem. The reason I think this is because Qemu acts as the Spice server if I am correct. Qemu relays information from a network socket assigned on the command line to the virtualized serial port and vice versa. Since an LXC installation is sans-Qemu server then I must use Xspice in order to take the place of Qemu and act as a Spice server in order to relay information between the agents/QXL driver and the Spice client. So, testing it within Qemu doesn't really reflect the problem at all. Beyond Qemu, there's really no way to test it sans-LXC. Actually, now that I think about it I may be able to run Xspice directly within a VM and then attempt to connect to it... I'll try that out later on and let you know how/if that works out. I may have to get that Fedora ISO after all just to broaden the test cases. I realize that I'm effectively attempting to use Spice outside of normal circumstances. However, the way that Xspice behaves -- such as creating its own versions of the virtio port (as a socket rather than a character device) and uinput (as a pipe) and attempting to destroy any existing versions of those files -- leads me to believe that Xspice was almost built for the purpose even if not intentionally. And, as I had said before, I got it mostly working in a Fedora LXC container (only lacking client functionality, which is why I asked for input in the first place ;). I would like to be able to provide a stack trace of the segfault I get in the Ubuntu LXC, but I'm unsure how to compile the sources with debugging symbols. Any help in that respect? On 11/27/2014 03:50 AM, Christophe Fergeau wrote: > On Wed, Nov 26, 2014 at 05:16:52PM -0600, Charles Ricketts wrote: >> Yes, I had seen those options. That was part of why I was asking about the >> ucds socket. I found now that the ucds socket is used to talk to multiple >> agents. I have tried both setting each argument to specify the paths of >> each piece (ucds socket, uinput, and virtio port) and letting Xspice set >> them up automatically. Xspice by default re-creates these devices as >> sockets and pipes, so it seems that Xspice is actually ideal for this >> purpose; there is no need to create the devices by hand. However, any way >> it's done even with the newest sources results in the same thing. In the >> Fedora LXC under Ubuntu 14.04, I get a display but no agent functionality >> for some reason even though the same ucds port is used by both agentd and >> agent. In an Ubuntu 14.04 LXC container I can't even get X to start via the >> Xspice script or a direct call to X because it segfaults when using the >> spiceqxl driver. >> >> There also appears to be no difference between letting the Xspice script >> start the agents or starting the agents by hand, which isn't unexpected. >> > Have you tried all of this without lxc to see how well/bad it works > without adding lxc to the mix? > > Christophe _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel