(for reference we're talking about making changes to libvirt default
configurations to always include virtio-serial channels so that Matahari
can use it w/o asking end users to add these themselves)
<snip>
There are two aspects. There is the device XML
<controller type='virtio-serial' index='1'>
<address type='pci' domain='0x0000' bus='0x00'
slot='0x0a' function='0x0'/>
</controller>
And then n * channels
<channel type='pty'>
<target type='virtio' name='org.linux-kvm.port.foo'/>
<address type='virtio-serial' controller='1' bus='0'
port='3'/>
</channel>
Normally applications would never add a <controller> themselves,
because it is done automatically when you add a <channel> device.
So making virtinst manually add a <controller> is not normal
practice.
Ok. So what we'd want here is to by default add a virtio-serial channel
in virtinst and vdsm with a name like 'org.matahari-project.port' (or if
we want to be more generic to this just being a qpid transport it could
be org.apache.qpid.port)
And adding that channel would make the creation of the virtio controller
implicit.
> If the former, then we should add a virtio channel by default on
the
> virtio-serial PCI device that we're adding. If we need to give a name
> to this, we could just call the channel mgmt or matahari or smth if it
> needs to be named.
We can't add a channel without knowing exactly how the application
that will use it, needs it to be configured which isn't something
we can reliably guess ahead of it being written.
What sort of configuration things need to be decided? Looking at the
channel snippet above it doesn't look unreasonable to decide what it
should look like and then implement the AMQP/virtio-serial transport to
use a preset configuration (assuming the important config info to decide
on is the channel name)
Perry