On 01/28/2011 11:38 AM, Daniel P. Berrange wrote:
On Fri, Jan 28, 2011 at 11:28:55AM -0500, Perry Myers wrote:
> (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)
No, we're not changing libvirt defaults.
We'll be changing the provisioning tools to add a virtio serial
channel for it when creating a new guest.
yes, it was inaccurate choice of language on my part. I meant libvirt
domain defaults controlled by virtinst, not 'libvirt core defaults'
> <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)
The type of channel, eg pty, unix socket, tcp socket, etc and the
config parameters associated with that type of channel, of which
there are quite a few possibilities. We really don't want to fix
this before the agent that will use it exists & has decided which
is best for its needs.
Ok. More complicated than I thought then :)
So yes, making this change in virtinst should block on Amit's
implementation of the AMQP/virtio-serial transport plugin.
Amit, please let us know when you get to a point where the above
configuration info is a known quantity.
Perry