Open Stack

On 11.08.2016 13:31, Daniel P. Berrange wrote:
> On Thu, Aug 11, 2016 at 07:19:42AM -0400, Sean Dague wrote:
>> On 08/11/2016 05:45 AM, Markus Zoeller wrote:
>>> On 26.07.2016 12:16, Jordan Pittier wrote:
>>>> Hi Markus
>>>> You don"t really need a whole new job for this. Just turn that flag to True
>>>> on existing jobs.
>>>>
>>>> 30/40 seconds is acceptable. But I am surprised considering a VM usually
>>>> boots in 5 sec or so. Any idea of where that slowdown comes from ?
>>>>
>>>> On Tue, Jul 26, 2016 at 11:50 AM, Markus Zoeller <
>>>> mzoeller at linux.vnet.ibm.com> wrote:
>>
>> We just had a big chat about this in the #openstack-nova IRC channel. To
>> summarize:
>>
>> The class of bugs that are really problematic are:
>>
>>  * https://bugs.launchpad.net/nova/+bug/1455252 - Launchpad bug 1455252
>> in OpenStack Compute (nova) "enabling serial console breaks live
>> migration" [High,In progress] - Assigned to sahid (sahid-ferdjaoui)
>>
>> * https://bugs.launchpad.net/nova/+bug/1595962 - Launchpad bug 1595962
>> in OpenStack Compute (nova) "live migration with disabled vnc/spice not
>> possible" [Undecided,In progress] - Assigned to Markus Zoeller
>> (markus_z) (mzoeller)
>>
>> Which are both in the category of serial console breaking live
>> migration. It's the serial device vs. live migration that's most
>> problematic. Serial consoles themselves haven't broken badly recently.
>> Given that we don't do live migration testing in most normal jobs, the
>> Tempest jobs aren't really going to help here.
>>
>> The dedicated live-migration job is being targeted.
>>
>> Serial console support is currently a function at the compute level.
>> Which is actually a little odd. Because it means that all guests on a
>> compute must be serial console, or must not. Imagine a compute running
>> Linux, Windows, FreeBSD guests. It's highly unlikely that you want to
>> force serial console one way or another on all of those the same way.
>> This is probably something that makes sense to add as an image
>> attribute, because images will need guest configuration to support
>> serial consoles. As an image attribute this would also help on testing
>> because we could mix / match in a single run.
> 
> There is actually image properties for this, but the way it is all
> implemented right now is just insane.

You're talking about "hw_serial_port_count" I assume? I'm not aware of
any other property for that. Sean was talking about enabling the serial
console per image/flavor property IIUC.


> For QEMU/KVM (on x86) currently, by default you get
> 
>  - a serial port which is connected to a file
>  - a serial port which is connected to a pty
> 
> If you turned on the serial_console option in nova.conf you instead get
> 
>  - one or more serial ports connected to a tcp port
>  - a serial port which is connected to a pty
> 
> The number of serial ports is based off an image property (
> hw_serial_port_count), but strangely the code doesn't honour a
> value of 0 for that. In addition the last serial port connected
> to a pty should really not even exist at that point.
> 
> We should aim to get to a place where we have 'serial_console.enabled'
> default to True in nova.conf and hw_serial_port_count setting how many
> are created, with 0 being a valid number. Never create any other serial
> ports that were not requested.
> 
> Regards,
> Daniel
> 

Allowing '0' as property value sounds like a good approach.

-- 
Regards, Markus Zoeller (markus_z)