Bug 615757

This issue has been proposed when we are only considering blocker
issues in the current Red Hat Enterprise Linux release. It has
been denied for the current Red Hat Enterprise Linux release.

** If you would still like this issue considered for the current
release, ask your support representative to file as a blocker on
your behalf. Otherwise ask that it be considered for the next
Red Hat Enterprise Linux release. **

There are a couple of options for representing this in libvirt

1. Pretend this is a new type of chardev backend

    <channel type='spicevmc'>
      <target type='virtio' name='com.redhat.com.spice.0'/>
    </channel>


2. Pretend this is a 'null' chardev backend, and detect solely based on name

    <channel type='null'>
      <target type='virtio' name='com.redhat.com.spice.0'/>
    </channel>

3. Invent a new type of channel and use null chardev backend still

    <channel type='null'>
      <target type='spicevmc'/>
    </channel>

I'm leaning towards option 2 currently.

Option 2 above would start a -device virtserialport,name=com.redhat.spice.0, right? That won't work.

I think -device spicevmc,name=foo,nr=NN is needed, so it more closely matches option 3 above.

Don't worry about what it maps to at the command line. All these options will require special hacks in libvirt, so that they map to the same command line Alan shows in the initial description. I'm more concerned about which description is most extendable/flexible at the XML level to cope with any extra features related to spicevmc in future.

This patch in fact implements option 1. An example usage is

         <channel type='spicevmc'>
           <target type='virtio' name='com.redhat.spice.0'/>
           <address type='virtio-serial' controller='1' bus='0' port='3'/>
         </channel>
    
'name' *must* equal 'com.redhat.spice.0' for now. We include this to allow for future expansion when/if spice needs multiple channels. Address can be omitted & will be auto-filled, unless an explicit virtio serial port number is required.

Created attachment 433727 [details]
Support spice agent device

libvirt-0_8_1-19_el6 has been built in RHEL-6-candidate with the fix.

Dave

#virsh edit rhel6-x86_64
Add the feature as following:
         <channel type='spicevmc'>
           <target type='virtio' name='com.redhat.spice.0'/>
         </channel>
#virsh start rhel6-x86_64

Log in the guest, and run:
#lspci
00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev 02)
00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II]
00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II]
00:01.2 USB Controller: Intel Corporation 82371SB PIIX3 USB [Natoma/Triton II] (rev 01)
00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03)
00:02.0 VGA compatible controller: Cirrus Logic GD 5446
00:03.0 Ethernet controller: Qumranet, Inc. Virtio network device
00:04.0 Multimedia audio controller: Intel Corporation 82801AA AC'97 Audio Controller (rev 01)
00:05.0 SCSI storage controller: Qumranet, Inc. Virtio block device
00:06.0 RAM memory: Qumranet, Inc. Virtio memory balloon
00:07.0 Communication controller: Qumranet, Inc. Virtio console

the output has the new device "Communication controller"
Status move to VERIFIED.

Red Hat Enterprise Linux 6.0 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.