nova instance console log empty
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
| OpenStack Compute (nova) |
Undecided
|
Unassigned | ||
| libvirt (Ubuntu) |
Undecided
|
Unassigned | ||
| nova (Ubuntu) |
Critical
|
Unassigned | ||
| qemu (Ubuntu) |
High
|
Christian Ehrhardt |
Bug Description
Nova instance console log is empty on Xenial-Ocata with libvirt 2.5.0-3ubuntu2~
James Page (james-page) wrote : | #1 |
James Page (james-page) wrote : | #2 |
James Page (james-page) wrote : | #3 |
Serial console snippet from xenial/ocata
<serial type='pty'>
<source path='/dev/pts/0'/>
<log file='/
<target port='0'/>
<alias name='serial0'/>
</serial>
<console type='pty' tty='/dev/pts/0'>
<source path='/dev/pts/0'/>
<log file='/
<target type='serial' port='0'/>
<alias name='serial0'/>
</console>
James Page (james-page) wrote : | #4 |
Note that this is with OpenStack Ocata, with the libvirt from zesty which is version 2.5.0.
This should be using the virtlogd capabilities of libvirt/qemu, but for some reason that's not actually working.
Changed in nova (Ubuntu): | |
status: | New → Triaged |
importance: | Undecided → Critical |
James Page (james-page) wrote : | #5 |
James Page (james-page) wrote : | #6 |
Might be related to bug 1599214 however qemu in use is 2.8.0 (and the empty log file issue should have been fixed in 2.7.0)
James Page (james-page) wrote : | #7 |
OK so a bit more information
I was able to virsh console to a running domain, login to the instance, reboot it and then disconnect from the console.
For the duration of the access, the console.log file was populated with the same data; after disconnect, the log file gets no more data.
Ryan Harper (raharper) wrote : | #8 |
I think this is the relevant qemu patch that we might need:
Discussion:
https:/
Changed in qemu (Ubuntu): | |
status: | New → Triaged |
importance: | Undecided → High |
assignee: | nobody → ChristianEhrhardt (paelzer) |
Christian Ehrhardt (paelzer) wrote : | #9 |
Thanks Ryan for doing all the search work!
@James - I have prepared a preliminary zesty version in a ppa at https:/
Since you very likely need that for your Xenial backport instead of the zesty version I pushed the commits to my LP repo, and you might want to experiment with those two on top of yours then:
https:/
https:/
There are a lot of CVEs for qemu 2.8 and I wanted to wait for a new Debian release to pick those up. That will still get into zesty release, but it could take a while, and I assume your schedule might be more aggressive.
I you happen to need this content here in zesty earlier please let me know and I'll plan for an extra upload/testing cycle.
Changed in nova: | |
status: | New → Invalid |
Changed in nova (Ubuntu): | |
status: | Triaged → Invalid |
Changed in libvirt (Ubuntu): | |
status: | New → Invalid |
Christian Ehrhardt (paelzer) wrote : | #10 |
If anybody wants to test, can be done against zesty ppa https:/
Launchpad Janitor (janitor) wrote : | #11 |
This bug was fixed in the package qemu - 1:2.8+dfsg-3ubuntu1
---------------
qemu (1:2.8+
* Merge with Debian;
This fixes several CVEs that were reported against qemu 2.8 and also
includes a few important functional backports (LP: #1667033); remaining
changes:
- add qemu-kvm init script and defaults file
(
- d/rules, d/qemu-kvm-init: add and install script loading kvm
modules and handling /etc/default/
- qemu-system-
- Enable nesting by default on intel.
- set default module option
- re-load kvm_intel.ko if it was loaded without nested=1
- d/p/ubuntu/
default in qemu64 cpu type.
- Enable svm by default for qemu64 on amd
- d/p/ubuntu/
define distro machine types to ease future live vm migration (includes
all former follow up fixes).
- Make qemu-system-common depend on qemu-block-extra
- Make qemu-utils depend on qemu-block-extra
- s390x support
- Create qemu-system-s390x package
- Include s390-ccw.img firmware
- qemu-system-
- change acl placed by udev, and add udevadm trigger.
- d/qemu-kvm-init, d/kvm.powerpc, d/control-in: check SMT on ppc64el
- Several changes were applied but missing in the changelog so far
- d/qemu-
- arch aware kvm wrapper
- update VCS links
- let qemu-utils recommend sharutils
- disable x32 architecture
- Enable seccomp for ppc64el
- Enable numa support for s390x
- d/qemu-
init.
- d/qemu-
command-
- Transition qemu-kvm to a systemd unit
- d/qemu-kvm-init, d/kvm.powerpc ppc64el SMT check avoid unwanted output
- d/qemu-kvm-init, d/kvm.powerpc ppc64el SMT check keep output local so
that it shows up where the user expects (sytemctl status, kvm stdout)
- d/qemu-kvm-init ppc64el warn on expected second level kvm-hv load failure
- add arch aware kvm wrapper for s390x
* Dropped Changes (in Debian now):
- d/p/ubuntu/
- d/control-in: change dependencies for fix of wrong acl for newly
created device node on ubuntu
- have qemu-system-arm suggest: qemu-efi; this should be a stronger
relationship, but qemu-efi is still in universe right now.
- Disable glusterfs (Universe dependency)
- no more skip disable libiscsi on Ubuntu
- d/rules, d/control-in: avoid people editing d/control
* Added Changes:
- d/control: bump libseccomp-dev dependency as enabling libseccomp for
power makes 2.3 the minimum level.
-- Christian Ehrhardt <email address hidden> Wed, 01 Mar 2017 14:23:16 +0100
Changed in qemu (Ubuntu): | |
status: | Triaged → Fix Released |
Tytus Kurek (tkurek) wrote : | #12 |
@Christian:
I've just tried with "2.8+dfsg-
Christian Ehrhardt (paelzer) wrote : | #13 |
Hi Tytus,
this ppa was only meant to pretest things for Xenial + Cloud Archive Ocata.
In Xenial there is a newer Qemu version SRUed in the meantime than the ppa had, so even enabling it won't install anything that fixes it for you - I'll kill the ppa to avoid this misunderstanding next time.
The situation as of now should be the following:
- In Zesty it should be fixed since 1:2.8+dfsg-3ubuntu1
- In Xenial+UCA-Ocata should be on 1:2.8+dfsg-
Could you check the latter or newer and report back here?
Serial console snippet from a trusty/mitaka install
<serial type='file'> srv/nova/ instances/ 0a33a19d- a310-4861- bf16-1bd5df8448 b7/console. log'/> dev/pts/ 21'/> srv/nova/ instances/ 0a33a19d- a310-4861- bf16-1bd5df8448 b7/console. log'/>
<source path='/
<target port='0'/>
<alias name='serial0'/>
</serial>
<serial type='pty'>
<source path='/
<target port='1'/>
<alias name='serial1'/>
</serial>
<console type='file'>
<source path='/
<target type='serial' port='0'/>
<alias name='serial0'/>
</console>