# spice-0.12.6-r2 - after upgrade, /dev/virtio-ports/ fail

## dufeu

Edit Dec 10, 2015

I've left the contents of my original post below and, armed with additional info, I am restating the issue/question I'm having. Also note that I may have completely misunderstood all the documentation I've read.

With the upgrade of spice to 0.12.6, spicec {a spice server for testing?} was removed. Previously, in order to use spice with a qemu client (in my case, a linux based guest), I would invoke qemu, qemu would pause and wait, then I'd execute spicec. qemu would continue booting the guest.

With the removal of spicec, the invocation of qemu was changed and the use of spice-vdagent was required. Actually, this isn't clear to me. I do understand that the guest must have an instance of spice-vdagent running. From what I've read, I believe the host also needs it's own instance to act as a system wide server. My further comments are based on this.

As I understand it, spice-vdagent has two modes of operation. Each guest is runs it's own instance of spice-vdagent. The host is expected to run spice-vdagentd. The script /etc/init.d/spice-vdagent attempts tp start both modes of spice-vdagent which is why there is a single script in /etc/init.d/.

When I try to start spice-vdagent on the host, I get:

```
# /etc/init.d/spice-vdagent start

 * Checking for required modules and devices ...

 * Required virtio port does not exist. Make sure you

 * started the virtual machine with appropriate parameters.                                                                                          [ !! ]

 * ERROR: spice-vdagent failed to start
```

The missing device is 

```
/dev/virtio-ports/com.redhat.spice.0
```

As I understand the updated QEMU documentation {see under 3.3 Invocation, subentry "-device"}, the Spice User Manual {see under Using Spice: Running qemu manually} and also from Arch Wiki - QEMU {see under Copy and Paste}, the invocation of qemu is supposed to create the needed device file. These are the qemu options for spice {formulated for inclusion in a 'sh' script and legibility}:

```
-device virtio-serial \

   -device virtserialport,chardev=vdagent,name=com.redhat.spice.0 \

   -chardev spicevmc,id=vdagent,debug=0,name=vdagent
```

The "-device virtio-serial" directive tells qemu to create the device and the next two options tell qemu what kind of device to create, what name etc.

I have no problem executing this much of the qemu invocation:

```
emu-system-x86_64 -enable-kvm -cpu host -m 1024 -smp 2 -vga qxl -drive file=/public/qemu/guynonet-q01,if=virtio -boot order=c,once=c,strict=on -netdev bridge,id=vnet0 -device virtio-net-pci,netdev=vnet0,mac=$( printf 'DE:AD:BE:EF:%02X:%02X\n' $((RANDOM%256)) $((RANDOM%256)) )
```

Up to this point, everything works as expected and I can log in both directly and remotely into the guest.

The complete {enabling spice} qemu invocation is supposed to be {assuming I read the documentation correctly}:

```
qemu-system-x86_64 -enable-kvm -cpu host -m 1024 -smp 2 -vga qxl -drive file=/public/qemu/guynonet-q01,if=virtio -boot order=c,once=c,strict=on -netdev bridge,id=vnet0 -device virtio-net-pci,netdev=vnet0,mac=$( printf 'DE:AD:BE:EF:%02X:%02X\n' $((RANDOM%256)) $((RANDOM%256)) ) -spice port=3001,disable-ticketing -device virtio-serial -chardev spicevmc,id=vdagent,debug=0,name=vdagent -device virtserialport,chardev=vdagent,name=com.redhat.spice.0
```

This just hangs waiting for some event.

Without spice, I can no longer do {between guest and host} transparent mouse movement, cut and paste, file transfers and window re-sizing. While this isn't the end of the world, it can be inconvenient and, at times, even annoying.

I have attempted to run spice-vdagentd on the host manually with these results:

```
 # spice-vdagentd -x -o -X

spice-vdagentd: no session info, max 1 session agent allowed
```

```
# ps -ef | grep spice

root     10759 13364  0 07:37 pts/19   00:00:00 spice-vdagentd -x -o -X

root     10832  9991  1 07:38 pts/46   00:00:31 qemu-system-x86_64 -enable-kvm -cpu host -m 1024 -smp 2 -vga qxl -drive file=/public/qemu/guynonet-q01,if=virtio -boot order=c,once=c,strict=on -netdev bridge,id=vnet0 -device virtio-net-pci,netdev=vnet0,mac=DE:AD:BE:EF:35:37 -spice port=3001,disable-ticketing -device virtio-serial -chardev spicevmc,id=vdagent,debug=0,name=vdagent -device virtserialport,chardev=vdagent,name=com.redhat.spice.0

root     11419 13357  0 08:14 pts/20   00:00:00 grep --colour=auto spice
```

 .. and still no creation of /dev/virtio-ports/com.redhat.spice.0

If anyone has the current version of spice working for their guest sessions, I'd really appreciate some input!

Original post:

With the update of app-emulation/qemu to 2.4.1 and the companion upgrades to all packages spice, the 'spicec' server has been dropped. Accordingly, I've been reading the updated Spice manuall trying to understand how to start my qemu sessions with spice support.

So far, I've gotten nowhere. If someone could clue me in to what I'm doing wrong, I'd appreciate it.

At the moment, I can't even boot my 'systemrescuecd' iso to do an install to a new qemu image. This is my current command as I understand it should be from the manual:

```
qemu-system-x86_64 -enable-kvm -cpu host -m 1024 -smp 2 -vga qxl -cdrom /sysrescd/systemrescuecd-x86-4.6.1.iso -drive file=q03,if=virtio -boot order=d -spice port=3001,disable-ticketing -soundhw ac97 -device virtio-serial -chardev spicevmc,id=vdagent,debug=0,name=vdagent -device virtserialport,chardev=vdagent,name=com.redhat.spice.0
```

What happens is that the command appears to be parsed and the installation iso and new qemu image are both found but then it just hands there waiting for something.

I do have spice-vdagentd already running in the background on the host. When running spice-vdagentd in the foreground, it gives me these messages:

```
# spice-vdagentd -x

spice-vdagentd: GetSeats failed: Failed to execute program org.freedesktop.ConsoleKit: Success

spice-vdagentd: no session info, max 1 session agent allowed
```

Some clues here or pointers to some working examples using the new versions of qemu and spice would be much appreciated.

----------

## gerdesj

This isn't a decent response to your real question but have you considered using something like libvirtd to do the complicated stuff?

I don't really know exactly what spice brings to the show (looks graphics related) but I do know that I run up several VMs on my laptop as needed and they just work.  I use the console or RDP or VNC or ssh etc to get at them as required.  I use KDE but libvirtd is a GTK job and it still just works.

It really depends on whether you just want to get the job done or fix a particular snag.  I don't know your use case but for me libvirtd generally gets the job done.

Cheers

Jon

----------

## dufeu

 *gerdesj wrote:*   

> I don't really know exactly what spice brings to the show (looks graphics related) ..

 

Spice allows for a number of 'ease of use' features including transparent cut&paste between host and guesst, transparent file transfers and such.

I especially like the whole transparent mouse focus thing between host and guest.

Previously, you would invoke your qemu guest, then qemu would wait until you started the 'spicec' server. Once the spicec server started, qemu would open it's window and start.

The qemu/spice upgrades are supposed to mean that 'spicec' server is no longer needed nor provided.

It's not something critical for me. Currently, I only use my guests as testbeds for tyring new packages, trialing -9999 ebuilds before putting them on my production (mostly video related) pcs and I have one 32bit guest for building x86 gentoo packages for later distribution to the 32bit pcs on my network.

As far as libvirt goes, I'm sort of 'old skool' in that I don't like inserting extra layers if I have a choice. It's a personal thing.  :Wink: 

I'll puzzle it out eventually. For my 32bit gentoo package building guest, I'm already invoking that without spice so that I can keep it's packages up to date.

----------

## dufeu

restated the original post based on new information

----------

