#ubuntu-s390x 2017-11-02
<cpaelzer> jfh: xnox: hey have you seen this on artful: http://paste.ubuntu.com/25871628/ ?
<cpaelzer> I'm on a rather old kernel 4.11 in Artful, so I reboot now
<cpaelzer> it might all be solved for ages but I wanted to ask to be sure
<xnox> cpaelzer, not sure. Is this lpar, z/vm, or kvm?
<cpaelzer> usually I remember ASCE differences with KVM, but this seems to pop up every now and then without a guest running
<cpaelzer> in lpar
<xnox> cpaelzer, are crypto CPACF (?!) instructions enabled in the HMC? and yeah 4.11 is not supported, so do check if you can reproduce with final kernels (4.13?)
<cpaelzer> I'll keep the dmesg up after the reboot is complete and IFF it shows again with the most recent kernel I'll file a bug
<cpaelzer> xnox: as you see I'm already on repro with 4.13
<cpaelzer> :-)
<cpaelzer> why would cpacf matter in this case, but well I can check
<jfh> cpaelzer: well, there are customer w/o CPACF (even if not many), so that should not be required ...
<cpaelzer> I'm on the default with both cpacf checkboxes set
<cpaelzer> the error is on a wrong ASCE which I only would connect with KVM - remember the old home/secondary setting
<cpaelzer> but as I said no guests required
<jfh> ^but didn't saw that so far - tried CDK on s390x on a artful machine last week which is causing heavy load and didn't came across this so far ...
<cpaelzer> I have another one on 4.13.0-16-generic without this issue
<jfh> cpaelzer: which LPAR are you using?
<cpaelzer> so lets assume it was just the too old kernel for now
<cpaelzer> s1lp5
<jfh> cpaelzer: settings look good ... (anyway, if you want to check if the system is really able to use CPACF just install libica-utils and run icainfo - but looks like 4.13 is fine anyway ...)
<cpaelzer> I never asked about cpacf, just referred to xnox question
<cpaelzer> but thanks for the double check jfh
<cpaelzer> and in any case this dmesg entry might still look known to e.g. hca - any known issue Heiko?
<hca> cpaelzer: that looks like a branch into nowhere-land ... if you would happen to know what was mapped at 0x3ff817064e0 then that might give you an idea
<hca> but this doesn't have to do anything with cpacf and/or kvm
<cpaelzer> hca: I don't know what was around that addr
<cpaelzer> hca: thanks for confirming my thoughts on what is not related
<cpaelzer> hca: if it happens again I'll look at the addr
<cpaelzer> hca: always gpr14 to look at?
<cpaelzer> need to find my old docs what usually is in 14
<hca> is this included in your kernel: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1708399
<hca> ?
<ubottu> Launchpad bug 1708399 in linux (Ubuntu Zesty) "kernel panic -not syncing: Fatal exception: panic_on_oops" [High,Fix released]
<cpaelzer> yes that would have been in
<cpaelzer> on the kernel I had
<cpaelzer> I really think this was just an too-old-non-released-kernel issue, don't spend too much cycles on it if it is not "ah that is Foo"
<hca> cpaelzer: gpr14 contains the return address if a function gets called
<cpaelzer> I found my  old s390x ELF spec pdf in the meantime
<cpaelzer> thanks
#ubuntu-s390x 2017-11-03
<borntraeger> do the cloud images have a default password for console login? "ubuntu" + "passw0rd" was documented some years ago, but this does not work when running the artful cloud image on kvm on z
<jfh> borntraeger: you may use smoser's script here to set a user and pw: http://bazaar.launchpad.net/~smoser/+junk/backdoor-image/view/head:/backdoor-image
<borntraeger> jfh, but that implies that the image "as-is" has no way to login via the hardware console. correct?
<jfh> borntraeger: well, looks like - the primary idea was to be used in an OpenStack context with keys ...
#ubuntu-s390x 2017-11-15
<xnox> cpaelzer, can i fake an ECKD drive with like file loop mounts?
<xnox> cpaelzer, to lift raw track data... even though the underlying is just a loop mount.
<xnox> in a QEMU kvm, not a z/vm
<cpaelzer> xnox: ah you have a raw track image and want to load that
<cpaelzer> xnox: how about dd it onto a spare dasd and providing that to the guest then?
<cpaelzer> so on host dd to disk
<cpaelzer> and then add the dasd to the guest
<cpaelzer> that is kind of a loop mount, but with a spare dasd instead of /dev/loop
<xnox> cpaelzer, i have no linda89@example.com.
<xnox> cpaelzer, i'm in kvm, need to create a raw track data dump. somehow =)
<xnox> cpaelzer, because for a z/vm cloud; i need to ship raw track data dump, not a tarball.
<cpaelzer> oh "inside" kvm
<cpaelzer> not on the host
<cpaelzer> I actually don't know
<cpaelzer> borntraeger: ^^
<cpaelzer> hca: ^^
<borntraeger> xnox, cpaelzer, not sure what you are trying to achieve.
<borntraeger> what kind of system do you have and what do you want to do
<cpaelzer> borntraeger: being inside a KVM guest and having a raw image of track data
<cpaelzer> borntraeger: being abel to mount it
<cpaelzer> that is the case xnox has if I got it right
 * cpaelzer feels there is an answer of the "you should know" kind coming
<borntraeger> what raw track image is this? How was it created?
<cpaelzer> xnox: what was the source ?
<xnox> cpaelzer, borntraeger, for normal ubuntu cloud images, we create a empty file, kparxt connect it, create partition table, debootstrap things on it, run zipl, unmount. and that ends up being a cloud image in qcow2 format that is bootable in s390x Ubuntu Openstack.
<xnox> cpaelzer, borntraeger - now, for the L1CC (original) / z/VM cloud connector / nova-zvm it needs raw track data. Thus in the past i would ssh into a z/VM
<borntraeger> So its an image file for z/VM guests?
<borntraeger> xnox, still do not get what kind of raw track file you have and how it was created
<xnox> and then i would qemu-nbd mount this qcow2 image, dd it onto a dasd drive, re-run zipl, switch the drive into raw track access mode, package that as a file and ship it to glance
<xnox> from where nova-zvm-driver takes that raw track data file, blasts it onto ECKD dasd drive to provision new z/vms
<xnox> however, currently launchpad builds everything in containers, and we create qcow2 image statically. And ideally, I should be able to create a raw track data of an eckd drive, without having a physical dasd drive to mangle.
<borntraeger> so you use a Linux under z/VM with the dasd driver in raw access mode to access the raw tracks after you have filled it with "normal means"
<xnox> borntraeger, can nova-zvm-driver use a non-raw-track-data image? but like a regular qcow2/raw iamge?
<borntraeger> xnox, I have no clue whatsoever about the z/Vm openstack driver
<cpaelzer> xnox: borntraeger knows everything but likely wants to stay away from nova-zvm things :-)
<xnox> borntraeger, currently yes; but ideally i do not want to =/ because my stock build environment has no dasd drives that i can abuse.
<xnox> borntraeger, i'm after to qemu-img convert -> raw track data; because surely it should be possible for the linux kernel, and/or userspace construct track data, which when dd'ed onto a dasd drive in raw track mode just "magically works"
<xnox> borntraeger, is there a defined data format of what raw track data is?
<borntraeger> xnox, I am sure that there is some way to construct the track data out of block data
<borntraeger> xnox, but I do not know
<borntraeger> xnox, maybe somewhere in the zdsfs fuse tool you find information about the track format
<borntraeger> xnox, s390tools/libzds/
<cpaelzer> borntraeger: do you think it would make sense to write to linux-s390 mailing list with that
<cpaelzer> borntraeger: for the other devs around you to check their toolboxes if one has something that achieves that?
<borntraeger> cpaelzer, yes  maybe.
<borntraeger> xnox, cpaelzer, wouldnt it be better if z/VM openstack would support a raw image?
<cpaelzer> oh yes of course
<borntraeger> the openstack thing uses xcat, which uses a Linux
<xnox> borntraeger, as long as i can force zipl to create the right boot code which would be bootable off dasd....
<borntraeger> so I would assume that this is possible
<borntraeger> xnox, you can force all kind of things with zipl
<xnox> borntraeger, my understand was that blasting raw image onto dasd, wouldn't end up with the right bootcode. I should test it.
<borntraeger> zipl.conf has targettype (e.g. CDL)
<borntraeger> and targetgeometry
<xnox> borntraeger, who can i talk to about image formats that the newly rewritten cloud connector supports.
<borntraeger> and targetblocksize
<borntraeger> xnox, no idea. its not us in Boeblingen
 * xnox somehow thought that zipl for CDL ends up on stuff outside of raw image and somewhere before it in the raw track data, but i guess not.
<borntraeger> xnox, its on the first track which is smaller than the usual 4k
<borntraeger> but when you write it the dasd driver ignores the additional bytes and fakes 4k
<xnox> borntraeger, right but the first track is "accesible" by dd when basting things to /dev/dasda which is in non-raw mode. ack.
<borntraeger> yes
<xnox> cool.
<borntraeger> xnox, "newly rewritten cloud connector" refers to whatever is on z/VM I guess?
<borntraeger> xnox, for the kvm openstack mpavone should be able to tell you everything
<xnox> borntraeger, i believe it refers to the "old xcat thing stuff to do openstack instances in z/vm" but rewritten / renamed / upgraded for newer openstack.
<xnox> borntraeger, kvm openstack is all good. we ship cloud images that are usable directly - just add a config drive, and voila.
#ubuntu-s390x 2017-11-23
<cpaelzer> arrr
<cpaelzer> hws stay here
<cpaelzer> mihajlov: hiho is the request for kvm_stat from/via you?
<cpaelzer> I'm interested (to understand the motivation) what the benefit is over pfer kvm ...
<mihajlov> cpaelzer: hehe ... I think borntraeger is best qualified to answer this
<borntraeger> cpaelzer, siehe update
<borntraeger> cpaelzer, die alten Daten im debugs zeigen Dinge, die du mit trace events nicht hast.
<borntraeger> cpaelzer, sorry in english: the old kvm stats in debugfs have a value that perf events cannot provide
<borntraeger> e.g. data after the fact
<borntraeger> cpaelzer, the kvm community now believes that kvm_stat has a value besides perf kvm
<cpaelzer> schon ok
<cpaelzer> thank you, the bug update is all we needed

{'channel': 'ubuntu-s390x', 'month': 11}