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 < >>>>> [email protected]> 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) __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
