#ubuntu-s390x 2016-04-04
<markus_z> jamespage: Hi James, a colleague notified me about https://bugs.launchpad.net/ubuntu/+source/nova/+bug/1564831 . I think in case of the libvirt driver its a config issue (as mentioned in comment #6). Feel free to ping me about Nova related things in the future. I also subscribed myself to bug reports for the project "nova (Ubuntu)" + tags "s390"|"s390x".
<ubottu> Launchpad bug 1564831 in nova (Ubuntu) "s390x: error booting instance" [Undecided,New]
<xnox> markus_z, sounds good. Note that we will never have "s390" tag, only "s390x". =)
<markus_z> xnox: OK, cool. It seems that "s390x" is not in the official tag list of the Launchpad project. Just a hint in case you want to add it.
<jamespage> markus_z, ack - will be doing some re-testing this week
<markus_z> jamespage: cool, let me know know the results please
#ubuntu-s390x 2016-04-06
<jfh> morning!
<hbrueckner> xnox, hi... I have an update regarding problem of loading dasd or zfcp (s390-zfcp, s390-dasd modules)
<xnox> hbrueckner, i am testing a local fix.
<xnox> =)
<xnox> hbrueckner, so my conclusion is that dasd/zfcp kernel modules are not loaded when dasd/zfcp steps run and hence they report "no bus/ nothing to activate"
<xnox> then hw-detect/disk-detect runs, loads dasd/zfcp kernel modules and then bails as nothing is available and it does not re-run dasd/zfcp-config
<hbrueckner> right... the point here is that it depmod -a behaves differently between ubuntu and debian
<xnox> my plan is to add $ modprobe dasd_mod/zfcp after the depmod in s390-dasd/zfcp postinst
<hbrueckner> depmod -a triggers device modprobing and causes the module to be loaded Debian
<hbrueckner> the better approach would be to simply call: update-dev
<xnox> but before the respective dasd-config/zfcp-config binaries are called.
<xnox> how come depmod is different in ubuntu though?!
<hbrueckner> sorry for pasting the diff her
<hbrueckner> --- a/debian/postinst
<hbrueckner> +++ b/debian/postinst
<hbrueckner> @@ -9,6 +9,11 @@ set -e
<hbrueckner>  test -x /sbin/depmod && depmod -a > /dev/null 2>&1 || true
<hbrueckner>  
<hbrueckner>  #
<hbrueckner> +# Trigger FCP discovery
<hbrueckner> +#
<hbrueckner> +update-dev
<hbrueckner> +
<hbrueckner> +#
<hbrueckner>  # Start the FCP configuration utility
<hbrueckner>  #
<hbrueckner>  exec zfcp-config
<xnox> http://paste.ubuntu.com/ is a thing you know =) also you can do
<xnox> $ git diff | pastebinit
<xnox> and on ubuntu that pipes and publishes things on the paste.ubuntu.com =)
<hbrueckner> .... if my systems would have access to the external network ;-)
<xnox> hahaha
<xnox> ok
<xnox> i have no idea what update-dev is though =)
<xnox> still worried that ubuntu's depmod -a is somehow bad.
<hbrueckner> it is part of the debian-installer-utils to and a wrapper around udevadm --trigger and --settle
<hbrueckner> update-dev actually is the --trigger
<hbrueckner> yep .... I thinkt that depmod  is part of busybox... perhaps a slightly different busybox version or config
<hbrueckner> xnox, I have to leave now... Thorsten might add some info to the LaunchPad these minutes
<xnox> ack
#ubuntu-s390x 2016-04-08
<xnox> hws, hello
<jamespage> rharper, hey - have 5 mins to help me debug a libvirt/qemu problem?
<rharper> sure
<jamespage> rharper, ok - so I nearly have instances booting under openstack - they do the normal startup -> paused whilst the networking is all being setup...
<jamespage> but then nova unpauses them and they just go straight to shutdown - not quite sure how to debug what's going on
<rharper> that's nova state saying shutdown ?
<rharper> versus actual console log ?
<jamespage> rharper, no that virsh list --all
<rharper> libvirt will always start the guest in stop mode (-S); then when all devices are attached, libvirt will send the cont signal to start the qemu machine
<jamespage> nova reflects that once it notices it
<jamespage> rharper, so I see
<jamespage>  -     instance-00000006              shut off
<jamespage> type stuff from virsh
<rharper> do we have the machine qemu.log file ?
<jamespage> rharper, the qemu log file for the instance - 2016-04-08T16:42:22.595065Z qemu-system-s390x: terminating on signal 15 from pid 260989
<rharper> that's likely to have info on why libvirt wants to shut it down
<rharper> ah
<jamespage> rharper, http://paste.ubuntu.com/15692628/
<rharper> i bet it's misconfigured and qemu is aborting
<rharper> can you enable libvirtd debugging and get a log from there?
<jamespage> rharper, I have the daemon running with the -v flag
<rharper> lemme get you a decent log config for libvirtd (less you have the qemu exec bits in our output)
<rharper> is that paste from your debug output or the instance.log file from var/lib/libvirt/qemu/$machine_instance.log
<rharper> I'm looking to see if qemu spit anything out on stderr
<jamespage> rharper, from the instance log file
<rharper> hrm, ok
<rharper> jamespage: I'm playing with the command line invoccation on another s390x box to see what qemu says;
<jamespage> rharper, okies - I can give you access to this one if you like
<rharper> sure
