Open Stack

On 11.08.2016 16:46, Markus Zoeller wrote:
> 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.

Nvm, I understand it now. The crucial point should be this one:

https://github.com/openstack/nova/blob/a059c8453ea3739e45ea1cc56eacc82603a25b0f/nova/virt/libvirt/driver.py#L4101-L4103

in combination with:

https://github.com/openstack/nova/blob/ad0047e97b2847412ee28bad6a3bfb48395add35/nova/virt/hardware.py#L198-L198

> 
>> 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.
> 

Let me check with a PoC how this could look like.


-- 
Regards, Markus Zoeller (markus_z)