#ubuntu-s390x 2016-04-01
<jfh> good morning
<andrewc> jfh, good morning!
<andrewc> jfh, sorry to hear that you're having difficulty getting online :-(
<andrewc> jfh, as well as your mail, you could also try asking for assistance on the "canonical-sysadmin" channel on freenode...
<jfh> good morning andrewc - well, I hope I can figure that out soon ... seems to be an issue with the Sign-in through Canonical ... let's see ...
<jfh> good point - will try that, too
<zachman> :D
<cpaelzer> jfh: welcome to the dark side
<jamespage> o/
<cpaelzer> hi jamespage
<cpaelzer> mihajlov: borntraeger: hi I hope you have a good weekend soon, but we would have a question regarding libvirt/kvm/openstack on s390
<cpaelzer> I hope it is one of the former two so we can get a quick solution without asking the OS guys :-)
<cpaelzer> jamespage: here in the channel hit thie bug just a few minutes ago
<cpaelzer> https://bugs.launchpad.net/ubuntu/+source/nova/+bug/1564831
<ubottu> Launchpad bug 1564831 in nova (Ubuntu) "s390x: error booting instance" [Undecided,New]
<borntraeger> cpaelzer, ?
<cpaelzer> mihajlov: borntraeger: and I wondered what/why you don't hit that with z/KVM+OS
<cpaelzer> the title is rather misleading IMHO
<cpaelzer> libvirtd[21610]: this function is not supported by the connection driver:  cannot update guest CPU data for s390x architecture
<cpaelzer> borntraeger: mihajlov: that is closer to where things might start to break
<borntraeger> cpaelzer, I would assume that this is about the "not yet available" cpu model support
<borntraeger> cpaelzer, mihajlov : but there was a workaround in libvirt for that
<jamespage> http://libvirt.org/git/?p=libvirt.git;a=blobdiff;f=src/cpu/cpu_s390.c;h=23a7f9d8d38a00dc9c673d224f797cf8a17aa5d1;hp=f9d7e216aec847df321d7c7d3a050415ee8550fd;hb=59403018893cf2c4f9a6f5145e387cefbd44399a;hpb=b789db36ae1cb5a48986c3b9e3bfb64131367872
<jamespage> looks relevant but we appear to have that in the libvirt version in xenial - just double checking
<jamespage> yah - confirmed in 1.3.1
<cpaelzer> jamespage: hmm - to be sure is that OS against libvirt/KVM ?
<cpaelzer> or containers anywhere in between?
<borntraeger> cpaelzer, jamespage , mihajlov its certainly a message from libvirt
<borntraeger> cpaelzer, jamespage, mihajlov , but I have not seen it here
<cpaelzer> jamespage: could you identify the exact (api) call it made to trigger that?
<jamespage> cpaelzer, borntraeger: actually yes there is a container in the way here
<jamespage> I think that's the cause of the problem...
<jamespage> empty /proc/cpuinfo is not helping I suspect
<cpaelzer> jamespage: do you want to give it a try without containers just with KVM ?
<xnox> jamespage, is missing /proc/cpuinfo an lxc/lxd bug, given that it needs to emulate/whitelist/synthesise it or some such?
<jamespage> xnox, yes I think so
<jamespage> cpaelzer, not just yet
<xnox> jamespage, i guess a manual provider can be mixed into the thing... ?
<jamespage> xnox, figured out how to bind mount the hosts cpuinfo into the container...
<xnox> ^_^
<jamespage> xnox, getting alot of "Failed to allocate directory watch: Too many open files"
<jamespage> xnox, cpaelzer: lack of /proc/cpuinfo is a problem for LXD, but does not appear to be the cause of this...
<jamespage> xnox, cpaelzer: trying a trick to add the host machine to the deployment, but just hit the wall with the 2G root disk size...
<xnox> jamespage, what's your host? you should be able to active e.g. additional drives and add them to the vgroup.
<xnox> jamespage, btw i can reboot s1lp7 and give it to you as well, as an additional resource it should have ~100GB large rootfs.
<jamespage> xnox, my problem is that all of the control plan IP addresses are on the local bridge and not generally accessible...
<jamespage> 2016-04-01 11:21:49 INFO install E: Write error - write (28: No space left on device)
<jamespage> not unexpected...
<cpaelzer> xnox: does d-i in guided partitioning try to create a swap disk as huge as memory?
<cpaelzer> xnox: the disk of james on a 40G memory system had split the available ~41G into 38.x swap and 2G root
<cpaelzer> xnox: s390 is the land of small disks and (sometimes) a lot of memory
<cpaelzer> xnox: there should/could be a cap on the swap size
<xnox> cpaelzer, jamespage: this is a classic d-i/partman bug. there are no caps, just multiples.
<xnox> deactivate swap, remove it, enlarge partition, enlarge rootfs....
<cpaelzer> xnox: already done that
<cpaelzer> I just wanted to avoid the next oen running into it
<cpaelzer> xnox: classic means the bug exists and is open=
<cpaelzer> ?
<xnox> https://bugs.launchpad.net/ubuntu/+source/partman-auto/+bug/1032322
<ubottu> Launchpad bug 1032322 in partman-auto (Ubuntu) "Swap space allocation for large memory systems needs improvement" [Medium,Confirmed]
<cpaelzer> great, thanks
<xnox> first opened in 2012-08-02 but it has been around since forever, and typically reported by installer testers in e.g. qemu vms with like
<xnox> "i gave it 16GB of ram and 8GB rootfs disk"
<xnox> thinking about it.
<xnox> cpaelzer, does it even make sense to have swap on lpar / z/VM?
<cpaelzer> xnox: don't get this started in a public channel
<cpaelzer> nooooo
<cpaelzer> you did it
<cpaelzer> this is like vim and emacs
<xnox> lpars should be big enough, and z/VM can over-commit x2 RAM
<cpaelzer> it can overcommit up to whatever you can accept performance wise and often I've seen 2-3x
<xnox> but on z/VM only, not on LPAR, right?
<cpaelzer> even on kvm it works reasonably most of the time although there could be soom improvements
<cpaelzer> LPAR is only partitioning, no overcommit for memory
<xnox> thinking about it, maybe there should be a safe guard that e.g. swap cannot be more than 10% of total disk space, regardless of the sizing relative to RAM
<cpaelzer> IMHO the Host should swap not the guests
<xnox> or maybe the 200% should be from the smallest of (ram, disk) sizes
<cpaelzer> but there are quite a lot of cases where that alone is not the truth
<cpaelzer> I think I have seen some logic that groups into three categories by ram size
<cpaelzer> ram <2G, try 2*ram
<cpaelzer> else swap = ram size
<cpaelzer> but
<xnox> can one at all hybernate lpar & z/VM? cause on server hibernate on emergency power shut down is a poor mans choice for redundant power.
<cpaelzer> never go over 64G
<cpaelzer> and never go over x% of the disks
<xnox> why 64G? why not 65G? why not 63G?
<cpaelzer> xnox: suspend and resume is implemented
<cpaelzer> arbitrary choice, like the old 2x, why not 1.8x
<xnox> suspend&resume is not hibernate&thaw. E.g. swap is not needed for suspend, as RAM remains powered/active.
<cpaelzer> if science people are involved we could suggest a smooth scaling formular no one would understand :-)
<xnox> 2x -> is reasonable to have a good chance at hibernate, when things have overcommited ram.
<xnox> cause one needs to dump all of ram to swap, to hibernate, plus whatever got overcommited/spilled over to swap.
<cpaelzer> ah you mean to disk
<xnox> yes, hibernate.
<cpaelzer> never cares too much about that, I'd have to check if that works as well
<cpaelzer> hca: ^^ ?
<xnox> is there hibernate on lpar / z/vm -> if not, i'll just remove swap from default recipes full stop, and people can install swapfile package to add swap.
<cpaelzer> wait for hca's answer
<cpaelzer> but then power failure is so boo low end
<cpaelzer> I mean most cpu calculations are doen twice for quantum effects of random particles
<cpaelzer> power failure - pffff
<xnox> i think mainframe deployements have better power failure mode handling than other architectures.
<cpaelzer> well - eventually they have way better handling, but then this is (sadly) one of the things the business/finance people cut costs
<cpaelzer> it works the same without that battery pack, well then ...
<xnox> >_<
<xnox> cpaelzer, reading all the bug reports it's like "high memory system -> too large swap" and "swap not large enough to hibernate"
<xnox> the most reasonable comment is from superm1
<xnox> https://bugs.launchpad.net/ubuntu/+source/partman-auto/+bug/576790
<ubottu> Launchpad bug 576790 in partman-auto (Ubuntu) "Partman should support disabling swap in impractical scenarios" [Undecided,New]
<xnox> e.g. it should be possible to have a flag to essentially "skip swap" and calculate that for "impractical scenarios" e.g. RAM >> root disk (high memory system)
<xnox> with a threshold as to what a high memory system is
<xnox> and be able to preseed that key.
<xnox> imho "high-memory" is anything where RAM >> 10% of total disk space
<xnox> (specifically 10% of the /usr partition)
<xnox> well... no.
 * xnox needs to look at partman-auto to see if it has total disk size numbers available
<cpaelzer> I'm ok with almost any limit, as the hard part is creating the infrastructure not defining the exact ratio/size of the limit
<jamespage> cpaelzer, borntraeger: OK so after looping around and re-deploying with the compute node directly on an LPAR running Ubuntu Xenial, I still see the same problem
<cpaelzer> jamespage: so you now run without Containers just KVM&Openstack
<cpaelzer> ?
<jamespage> cpaelzer, well the control plane bits are still in containers but the hypervisor is not
<cpaelzer> ok
<cpaelzer> didn't xnox already say it worked for him, maybe he has the workaround you need
<xnox> not with latest nova generated libvirt config for our cloud image
<jamespage> xnox, yeah - I suspect this is a break in nova's used of libvirt but not 100% sure yet...
<xnox> so we will need to debug the generated libvirt config i guess.
<xnox> jamespage, is the one you pasted on the bug report accurate?
<xnox> most recent
<jamespage> xnox, yes
<xnox> cool, i'll give it a poke in a few.
<xnox> need to finish a few things up, and have a call, and then will be able to look into it.
<jamespage> xnox, having a punt at setting the cpu-mode flags for nova to host-passthrough
<jamespage> xnox, we do the same for ppc64el
<jamespage> xnox, have you hit this "too many open files" warning/error on s390x?  I think its actually impacting my deployment
<jamespage> I see it on the host and in containers as well..
<mpavone> Hi, I have updated a comment to https://bugs.launchpad.net/ubuntu/+source/nova/+bug/1564831 regarding instance not starting on s390x
<ubottu> Launchpad bug 1564831 in nova (Ubuntu) "s390x: error booting instance" [Undecided,New]
#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
#ubuntu-s390x 2016-04-11
<jamespage> markus_z, switching to cpu-mode = 'none' fixed things sufficiently to get a cloud up and running
<jamespage> albeit in all on lpar using containers, but a useful validation point all the same
<markus_z> jamespage: cool! Good to hear that. Thanks for the info.
<markus_z> jamespage: Did I already mention that VNC is not working and you need the "serial console" if you want to access it in Horizon?
<markus_z> "it" == an instance
<jamespage> markus_z, ah - no I did not know that
<jamespage> tbh I generally avoid horizon
<jamespage> but thanks for the feedback anyway
<markus_z> jamespage: good choice :)
<jamespage> serial console is not configured by the charms atm - I'll add that to the features list for next cycle...
<markus_z> jamespage: The serial console still has limitations though. Live-migration is not possible with it. I'm working on a bug fix for that.
<markus_z> https://bugs.launchpad.net/nova/+bug/1455252
<ubottu> Launchpad bug 1455252 in OpenStack Compute (nova) "enabling serial console breaks live migration" [High,In progress]
<xnox> markus_z, hm, surely we can connect to the virtio console and have migrations working et.al.? (same as on other arches)
 * xnox looks into the bug report
<markus_z> xnox: It's not related to the arch. It behaves the same on x86. The way nova handles the ports during the live-migration is the root cause.
<xnox> ah, ok =)
<xnox> markus_z, i meant VNC -> i thought that should work without serial console, and simply with the /dev/hvc0 console no?
<xnox> hvc0-7 consoles
<markus_z> xnox: That' news to me. Isn't hvc0 xen related?
<xnox> markus_z, it might be qemu 2.5 new stuff. And yes hvc0 is usually xen stuff. I'll boot another instance on my machines in a moment to inspect available things.
 * xnox ponders if there is Xen on s390x
<smb> xnox, no
<xnox> either something is recycling the names, or possibly ubuntu config has xen stuff enabled =/
<xnox> (kernel config)
<smb> I think hvc is Xen but not only, there was something else using that name (thoug I thought ppc)
<markus_z> I have to leave for today, we can talk tomorrow about this if you like.
<xnox> cpaelzer, infinity, smb - could you take a look at the last patch I've posted on https://bugs.launchpad.net/ubuntu/+source/update-notifier/+bug/1563854 ?
<ubottu> Launchpad bug 1563854 in update-notifier (Ubuntu) "update-notifier updates-available does not reset after dpkg run" [High,Fix released]
<xnox> it seems reasonable to me, but I'm not sure if it will re-introduce the stalls you have worked on removing in previous uploads.
<xnox> i'm gonna run in that config for a bit, and see if it's reasonable.
<smb> xnox, I can try this as a manual fix, too. It looks reasonable and I guess the stalls were mainly because the cache was updated on every login. Now it would be only when running update or upgrade
<smb> which I think is already protected somehow against concurrent runs
<cpaelzer> xnox: looking
<cpaelzer> xnox: yeah that update was lost, and currently has the delay til next update
<xnox> cpaelzer, so currently story: apt update, ssh localhost "you have X updates", apt full-upgrade, ssh localhost "you have X updates", apt update, "<no updates message>"
<cpaelzer> xnox: I agree on "recounting" after DPkg ran to be a proper solution
<xnox> cool.
<cpaelzer> I haven't tested
<xnox> with this thing after dist-upgrade (even if partial) the right new count is displayed.
<cpaelzer> do you want us to test it too, any ppa or anything?
<xnox> i'll test it more with partial / aborted upgrades later on, before uploading.
<cpaelzer> or just test itonce upload is through?
<xnox> cpaelzer, it's a conf file, just edit it in /etc/apt.conf.d =)
<cpaelzer> xnox: so true
<xnox> to match the new stanza.
<cpaelzer> xnox: let me get my numa "Â§$%& out of the way and I'll test it later one
<xnox> =)
 * xnox wishes dasdfmt was faster
<cpaelzer> xnox: your fixe worked for me in general and in the few tests I've made
<cpaelzer> xnox: it achieves what you wanted and it didn't break anything for me that I would have noticed
<xnox> cpaelzer, cool. I was after that!
<cpaelzer> and the extra latency is only added to another apt/dpkg action which is where it should belong to
<cpaelzer> as you remember it was "on login" in the past which was horrible waiting these seconds over and over again :-)
<xnox> yeap
#ubuntu-s390x 2016-04-12
<cpaelzer> morning little z systems out there
<jfh> morning
<xnox> cpaelzer, yeah \o/
<xnox> little or under heavy load =)
<cpaelzer> xnox: I fail to get the context :-)
<cpaelzer> xnox: but yeah \o/ at least doesn't sound too scary
<xnox> cpaelzer, "<cpaelzer> morning little z systems out there"
<cpaelzer> xnox: ah that important one - sure
<cpaelzer> xnox: you are long enough working on z now - you should get to learn all the common statements of s390 fans
<cpaelzer> like "never trust a computer you can lift" - while not invented for z it totally applies
<xnox> heheh
<xnox> so i guess "little z systems" is a tongue-in-cheek statement. =)
#ubuntu-s390x 2016-04-13
<xnox> cpaelzer, do you know at all how to enable z/vm monitoring?
<xnox> https://www.ibm.com/support/knowledgecenter/linuxonibm/com.ibm.linux.z.lgdd/lgdd_t_monst_setup_gvm.html?lang=en
<cpaelzer> xnox: what you linked is for Linux to provide extra data to the monitor
<cpaelzer> xnox: do you mean that or how to enable monitoring in general so that you can feed data into it?
<xnox> cpaelzer, yes.
<xnox> cpaelzer, i did all the linux side things, and the kernel is telling me "not allowed to write data"
<xnox> so i assume that monitoring is not enabled on z/VM side of things, and/or e.g. i didn't bring online the needed CCW device or some such.
<cpaelzer> I always used monitor stuff for performance data, never for appldata - but I should be able to find a redbook or so that describes the host portion of it
<xnox> cpaelzer, i thought MONITOR SAMPLE ENABLE APPLDATA ALL et.al. are z/VM CP commands, no?
<cpaelzer> give me a sec
<xnox> i tried to run that through #vmcp and it told me to go away =(
<cpaelzer> they are cp commands
<cpaelzer> but you have to have that stuff installed
<cpaelzer> what you have looks like the config for monwriteer
<xnox> "Set this option in the z/VM user directory entry of the virtual machine in which the application that uses this device driver is to run:"
<cpaelzer> yep
<xnox> what is z/VM user directory? how do i check which options it has? how do i change them?
<cpaelzer> consider it a bit (only a bit) the virsh.xml of your guest
<cpaelzer> depending on permissions you can modify yours - more often you need an admin login
<cpaelzer> you can (try to) edit your current profile - usually with "x profile exec a"
<cpaelzer> x is the editor
<cpaelzer> be aware if you thought vi is strange a decade ago
<cpaelzer> "profile+exec" is like "file+extension"
<cpaelzer> a is where it is -on your a disk
<cpaelzer> when you log on to a guest
<cpaelzer> then your profile is executed
<cpaelzer> ah you forgot the CP
<cpaelzer> well no vmcp already goes to cp
<xnox> cp says unknown monitor command, if i like get a c3270 console up
<cpaelzer> I'd recommend x3270
<cpaelzer> http://www.redbooks.ibm.com/redbooks/pdfs/sg248147.pdf
<cpaelzer> contains an example on editing your profile
<cpaelzer> on page 247
<cpaelzer> they even have the enables you wanted
<cpaelzer> they enable more - for the perf monitoring that I mentioned
<cpaelzer> section 9.4.1 is what you currently d
<cpaelzer> do
<cpaelzer> there is a reference for "OPTION APPLMON"
<cpaelzer> I never needed to set that, but then my systems always might just have had it enabled by some friendly admins
<cpaelzer> Option applmon is for your directory entry
<cpaelzer> that now is the real counterpart to a virsh.xml
<cpaelzer> rule of thumb:
<cpaelzer> directory entry = virsh.xm
<cpaelzer> profile = autoexec.bat (yes old win example I know)
<cpaelzer> page 183 has an example of the option being enabled in the driectory
<cpaelzer> FYI - DIAG X#DC' seems to be the way it is implemented - see http://publib.boulder.ibm.com/epubs/pdf/hcse5c00.pdf
<cpaelzer> that is how the hipercall is made from linux to the hipervisor
<cpaelzer> but that is done for you in the appl* modules
<cpaelzer> just if you ever need to debug it
<cpaelzer> you might need inaddy or an IS admin to change your directory
<cpaelzer> I currently look for a query how you could check if it is enabled
<cpaelzer> xnox: ^^
<xnox> cpaelzer, x3270 is aweful -> c3270 is so much better. I have a high dpi screen laptop, and x3270 is unusable. Plus c3270 has everything too.
<xnox> curses, but yeah.
<cpaelzer> whatever works for you
 * cpaelzer lacks $ for high DPI
<cpaelzer> http://www.ibm.com/support/knowledgecenter/SSB27U_6.2.0/com.ibm.zvm.v620.hcpa5/option.htm%23option
<cpaelzer> about setting OPTION APPLMON
<xnox> it came out of my toys budget =)
<cpaelzer> familiy consumes toy budged
 * xnox is single :-P
<cpaelzer> xnox: what does "vmcp query monitor all" give you
<cpaelzer> I really think we need to check that it is enabled as step1
<xnox> $ sudo vmcp query monitor all
<xnox> [sudo] password for ubuntu:
<xnox> HCPCFC003E Invalid option - MONITOR
<xnox> Error: non-zero CP response for command 'QUERY MONITOR ALL': #3
<cpaelzer> that seems very disabled/unavailable to me
<cpaelzer> there should have been so much stuff in the report - like if the appldata domain is active and all that
<cpaelzer> https://www.ibm.com/support/knowledgecenter/SSB27U_6.3.0/com.ibm.zvm.v630.hcpb7/qmon.htm
<cpaelzer> but it seems monitor itself is unavailable - as I said I always had the luxury of such basics being set up :-)
<cpaelzer> lets consider it is not installed7enabled
<cpaelzer> xnox: I've asked a few people that should know better - need to wait til they reply
<xnox> cool
<xnox> thanks!
<cpaelzer> xnox: there might be my family-evening-break in between, but I definetly come back to you later
<cpaelzer> xnox: well we are totally without privileges
<cpaelzer> xnox: even to query if enabled it need a user with A or E
<cpaelzer> but we only have G
<cpaelzer> That very likely applies to your enable as well
<cpaelzer> we need someone to change the entries of you login
<cpaelzer> while doing so he can ensure you have Option applmon enabled
<cpaelzer> inaddy: ^^ - can you do that ?
<cpaelzer> RT ticket ?
<cpaelzer> also I really think that xnox user should get like ABEGU privclasses
<xnox> wel.... maybe not.
<cpaelzer> xnox: yes the MONITOR command for your enable is Priv class A and E as well
<cpaelzer> so without that you won't do a lot :-)
<cpaelzer> xnox: so really - open a RT ticket to get your z/VM login (that of your guest) also priv class A and E
<cpaelzer> xnox: otherwise I don't see you continuing to work on this
<cpaelzer> and once you have that you can start with the query to see what actually is enabled
<cpaelzer> then enable it with the command you already had
<cpaelzer> then query again
<cpaelzer> then cross fingers and do it
<cpaelzer> xnox: away with the kids for a while, let me know if you need more
<inaddy> sorry guys my daughter was born yesterday. still in hospital. could u ping frank
<inaddy> cpaelzer: ^
<cpaelzer> inaddy: absolutely - I hope everything is fine - and gratz
#ubuntu-s390x 2016-04-14
<jgrimm> hi, docker guy got access to ubuntu beta2 and noticed xubuntu-desktop installed (promptly removed to get himself 2G back).   seemd odd to have a desktop package on z, so thought i'd poke in here
#ubuntu-s390x 2016-04-20
<jfh> good morning!
#ubuntu-s390x 2016-04-21
<xnox> hws, wait for a release announcement.
<xnox> hws, as per #ubuntu-release-party instructions =)
<xnox> it's out
<jfh> @xnox: juhu !
#ubuntu-s390x 2016-04-22
<AlexKim> Hello, has anyone tried to install Ubuntu on zKVM?
<slangasek> AlexKim: there are cloud images that are supported for booting in place under KVM: https://cloud-images.ubuntu.com/releases/xenial/release/
<AlexKim> slangasek: thanks. I have image downloaded but having trouble moving forward installing on zKVM....when selected 'Abort Installation' it keeps rebooting to installer.
<AlexKim> slangasek: Is cloud image different from regular iso image?
#ubuntu-s390x 2016-04-26
<Bercik> Hello.
#ubuntu-s390x 2016-04-27
<macjl> Hello
<macjl> I'm trying to install Unbuntu in LPAR
<macjl> But facing problems with VLAN tagging
<macjl> The installer don't ask me if I use VLAN, so the network does'nt work...
<macjl> Anyone know how to net install ubuntu on s390x arch with VLAN tagging?
<xnox> macjl, you have two options
<xnox> macjl, return to main menu ("<")
<xnox> change debconf priority to medium
<xnox> then it should ask you to use vlan, but that may or may not work.
<xnox> i typically "go through the motions up to ssh client password setup"
<xnox> then return to main menu
<xnox> drop to shell
<xnox> and bring up vlan network by hand, e.g.
<xnox> ip link set dev encc000 up
<xnox> ip link add link encc000 name encc000.2654 type vlan id 2654
<xnox> ip addr add 636-721-3251/24 brd 636-721-3251 dev encc000.2654
<xnox> ip link set dev encc000.2654 up
<xnox> ip route add default via 636-721-3251
<xnox> echo nameserver 636-721-3251 >> /etc/resolv.conf
<xnox> ..
<xnox> adjust as needed.
<xnox> you would then have to bring up network by hand again in the installed system, and adjust /etc/network/interfaces
<xnox> work is in progress to improve vlan network support. Do let me know your experience with debconf medium priority that does ask for vlan network tag.
<macjl> Thans, I'll try!
<xnox> macjl, no problem. =)
<Bercik> It's good to see people alive on s390* channels :)
<xnox> Bercik, yeah =) slowly picking up.
<Bercik> I remember idling +/- 9 months on hercules channel. Not even one word :)
<xnox> hehe
<xnox> honestly i have tried hercules, but did not manage to boot anything in it =(
<Bercik> I did
<Bercik> but not with ubuntu ;(
<Bercik> nor modern distros (RHEL 7, SLES 12).
<xnox> yeah, cause ubuntu needs transactional memory and like zEC12 or better cpu
<xnox> i don't think hercules has emulation for that
<Bercik> I tried newest 4.0
<xnox> i wish qemu had system emulation on other platforms, but that's not in for same reasons arm64 foreign emulation is not there
<xnox> hm, i did not try 4.0 from github, right?
<Bercik> yup,
<Bercik> It runs debian 8 with no problems. Same for my rusty z/OS 1.10
<xnox> https://github.com/hercules-390/hyperion/issues/39
<xnox> we need that for ubuntu
<Bercik> Depends on my CPU config. After IPL it ends up with "you need more recent hardware" or Wait State
<Bercik> xnox,   --enable-interlocked-access-facility-2=yes|no
<Bercik>                           enable/disable Interlocked Access Facility 2
<Bercik>                           (default yes)
<Bercik> this is mentioned multiple times, when talking about Linux IPL, and this new version seems to has it.
<xnox> no idea. i just know that both kernel and glibc use transactional memory on ubuntu (and other modern distros too)
<xnox> and that needs transactiona-execution facility
<xnox> i don't know what this interlocked access facility is, and/or if transactional memory/execution is implemented using above in hercules
<macjl> For infomation, with debconf priority set to medium, I was able to choose a VLAN ID
<macjl> But after installation, the configuration was not ste in /etc/network/interfaces
<macjl> I had to set it up manually
<xnox> macjl, ack. thanks.
<xnox> will investigate and will try to fix that up.
<xnox> macjl, if you wish you can open a bug report about that with $ ubuntu-bug debian-installer
<xnox> or open one on launchpad manually against ubuntu project, debian-installer package, and attach logs from /var/log/installer
<xnox> if you can/allowed to share those.
<macjl> I'll see if I can
<macjl> Now I'm trying to make bonding work with vlan....
<xnox> macjl, =))))) it should work, i try to avoid fiddling with things like that, and just defer it to infrastructure team =)
<macjl> It worked with VLAN + bonding. I've just moved a VM from IBM KVM to Ubuntu (offline) with no problems :)
<macjl> It doesn't seem to work with live migration because of a SELinux problem :
<macjl> error: unsupported configuration: Unable to find security driver for model selinux
<xnox> macjl, right. in ubuntu we support live migration among our hypervisors (e.g. lxd to lxd, qemu to qemu)
<xnox> i don't know if it's possible to move things form z/KVM to Ubuntu live.
<xnox> macjl, could you open a bug report about that? because surely we should be able to translate selinux model to apparmor (which is what used to protect qemu on ubuntu) and/or give option to ignore selinux context for migration (sub-optimal, but better than failing outright)
<xnox> maybe we can enable selinux in relevant parts of the stack to make migrations work too.
<xnox> if you add tag "s390x" to the bug report, I will notice it and can route it appropriately to the right ubuntu teams
#ubuntu-s390x 2016-04-28
<mihajlov> xnox, as a followup to the discussion you had with macjl, guest migration between different KVM versions needs more consideration than the security driver used
<mihajlov> e.g. the target hypervisor must understand and support the machine type as defined on the source hypervisor
<mihajlov> a guest defined on KVM for IBM z will by default have a machine type of s390-ccw-kvmibm-1.1.1
<mihajlov> which won't be accepted by an upstream QEMU
<mihajlov> one could define the guest with machine type of s390-ccw-virtio-2.4 on the KVM for IBM z hypervisor which would allow the migration to an upstream hypervisor (like Ubuntu)
<xnox> mihajlov, right.
<xnox> mihajlov, forgot that part. When I saw this different machine type, i was slightly surprised and confused why a new one got defined.
<xnox> mihajlov, I can certainly take that machine type as a patch to Debian & Ubuntu qemu, if we do in fact support / are compatible two way between 2.5 and e.g. s390-ccw-kvmibm-1.1.1
<mihajlov> regarding the selinux <-> apparmor conversion I have doubts whether an automatic conversion can be vouched to be safe
<xnox> true
<mihajlov> as a potential way out, it is possible to send a modified domain XML over to the target machine using the --xml option on the migrate command
<xnox> mihajlov, i wonder if we can, and/or should enable selinux in qemu on ubuntu. we have selinux anabled in a bunch of things
<mihajlov> where you could omit the security driver
<xnox> (and e.g. smack too)
<xnox> mihajlov, would z/kvm accept --to-ubuntu flag? =)
 * xnox is biased and wants everything on ubuntu ;-)
<mihajlov> xnox, wrt to selinux on Ubuntu I am not a security expert but I thought you'll have to chose one method for your system?
<xnox> apparmor is default and integrated throughout.
<xnox> however other systems are available too, for those that want to use them.
<xnox> e.g. we had selinux enabled in upstart as pid 1, because there are selinux usecases that people resonably use.
<mihajlov> xnox, regarding the flag: to have one would be less of a problem (of course it would be one upstream) then the semantic associated with it
<xnox> --insecure or some such =)
<mihajlov> there's no way to "downgrade" a running virtual machine without impacting the guest
<xnox> i dunno if libvirtd can do multiple security models simultaniously.
<xnox> ouch.
<mihajlov> would be a matter of testing I think
#ubuntu-s390x 2016-04-29
<borntraeger> xnox, regarding machines types 1.1.1 is somewhere in between 2.4 and 2.5, so please do not provide these machine type names for ubuntu/debian
#ubuntu-s390x 2018-04-21
<R7MQ3Fzsin> https://www.youtube.com/user/l0de/live IS POPPIN HOT RIGHT NOW STILL GOING!! CALL 636-721-3251. IRC.EFNET.ORG #lrh
<R7MQ3Fzsin> jfh cpaelzer mwhudson MaStr-- dragan-s elmo slashd intheclouddan ejat slangasek smb Loopeth|aka|kip pppingme xnox Bercik ubuntulo13 cjwatson tinoco ubottu kwmonroe brookswarner moon127 wgrant

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