=== not_phunyguy is now known as phunyguy
[07:11] <calcmandan-tab> i have an severely out of date server on 15.04 and looking for directions of updating severely eol ersions. can someone kindly send me a url?
[07:54] <lotuspsychje> calcmandan-tab: is that a test server or production?
[08:03] <calcmandan-tab> foud it
[08:03] <calcmandan-tab> found it
[08:03] <calcmandan-tab> fingers crossed i don't hose my server
[08:04] <lotuspsychje> calcmandan-tab: a lot of security flaws have been released since 15.04 are you sure you take the risk of eolupgrade?
[08:05] <calcmandan-tab> lotuspsychje: not sure what the risk is
[08:06] <lotuspsychje> calcmandan-tab: were your servers connected to internet or offline use?
[08:06] <calcmandan-tab> both
[08:06] <calcmandan-tab> but not critical
[08:06] <lotuspsychje> !usn | calcmandan-tab security risks
[08:06] <ubottu> calcmandan-tab security risks: Please see https://usn.ubuntu.com/ for information about recent Ubuntu security updates.
[08:07] <lotuspsychje> calcmandan-tab: if its for production use, id really reccomend fresh install to be sure your server isnt compromized
[08:07] <lotuspsychje> maybe its not, but why take the risk right?
[08:07] <calcmandan-tab> i did a major scan of the server and i have strong egress rules on the firewall
[08:07] <calcmandan-tab> i also reviewed its logs
[08:08] <calcmandan-tab> firewall and proxy logs
[08:08] <lotuspsychje> calcmandan-tab: ok then if you know what youre doing :p
[08:32] <cpaelzer> jamespage: did your issue with OVS 2.12 resolve?
[09:11] <Aison> hello, can I disable the network-manager.service, when I do not use the /etc/network/interfaces facility? is it enough to keep just systemd-networkd.service enabled?
[09:24] <lordievader> Aison:  You mention three different methods of configuring network interfaces here. What do you actually use?
[09:24] <calcmandan-tab> lotuspsychje: thanks for your help earlier.
[09:25] <lotuspsychje> calcmandan-tab: welcome mate
[09:25] <calcmandan-tab> lotuspsychje: i'm taking your advice as it'll be much quicker to go fresh
[09:25] <calcmandan-tab> lotuspsychje: and cleaner
[09:25] <lotuspsychje> +1 nice choice calcmandan-tab
[09:26] <calcmandan-tab> night
[09:26] <calcmandan-tab> take care
[09:26] <Aison> lordievader, i'm only using the systemd facility
[09:27] <lordievader> In that case NetworkManager and ifupdown (`/etc/network/interfaces`) can safely be disabled.
[09:27] <Aison> so I placed config files into /etc/systemd/network
[09:27] <lordievader> Do make sure the `systemd-networkd` service is enabled and running.
[09:28] <lordievader> If you are able to, reboot at least once to check if the configuration is reboot-proof.
[09:28] <Aison> ok
[09:28] <Aison> I just wonder, why networkmanager replaced my reslov.conf by an empty file (except containing # Generated by NetworkManager)
[09:29] <lordievader> Because it likes to control it with information either from DHCP or manually supplied.
[09:29] <lordievader> If you are doing this remote, make sure you have some backup method of access (IPMI).
[09:31] <Aison> the funny thing is, altough resolv.conf has no nameserver defined, nslookup, dig, etc... is still working.
[09:31] <Aison> is automatically the localhost used if there is no nameserver defined? because i'm running bind on this machine
[09:31] <lordievader> The DNS was designed this way.
[09:32] <lordievader> As a way to push over people to the DNS (instead of the hosts file) the fall-back default would be localhost.
[09:35] <Aison> lordievader, ok, thx :-) /etc/network/interfaces is read by the network-manager.service or are these two different facilities?
[09:36] <lordievader> NetworkManager only reads that file to figure out which interfaces are managed by ifupdown, furthermore it does its own thing. NetworkManager is not configured through `/etc/network/interfaces`.
[09:44] <Aison> brb, reboot server :-D
[09:47] <Aison> lordievader, ok, everything works fine without network-manager.service ^^
[10:02] <lordievader> Good to hear
[10:59] <Aison> argh, why is mariadb logging everything...  just deleted a 500gb log file
[11:03] <Aison> oh, somehow general-log was enabled....
=== Wryhder is now known as Lucas_Gray
[13:32] <hallyn> cpaelzer: yeah, so qemu supported virtio-scsi-blk, but the eoan server livecd couldn't find the disk :(
[13:32] <hallyn> i'm being lazy - haven't looked at the available kernel modules yet
[13:33] <hallyn> jamespage: cpaelzer mentioned that rharper had suggested you switch to virtio-scsi, did you do so, and did you have any troubles?
[13:44] <hallyn> oh you know what - never mind,
[13:44] <hallyn> i using the $(*&^&(*#&$(*#&$(* "improved" qemu command line wrong
[13:45] <hallyn> man i hate the -device crap.  and now, apparently, you have to use *3* pairs of arguments for one stinking drive.  lovely
[13:45] <hallyn> but, it's working :)  now to test discard
[13:46] <cpaelzer> IMHO the cmdline no more is meant to be a human interface
[13:46] <cpaelzer> more for machine generated strings
[13:47] <cpaelzer> I happen to use the most outdated (but easy to remember) arguments as well every now and then
[13:47] <hallyn> yeah...
[13:49] <hallyn> i bet there's a front-end out there that parses easier to remember cmdline to qemu cmdline :)  maybe i'll turn my 'kvm' script into one
[13:50] <hallyn> "-virtio-scsi-drive x.qcow2" -> if=none,id=hd,file=x.qcow2,format=qcow2 -device virtio-scsi-pci,id=scsi --enable-kvm -device scsi-hd,drive=hd
[13:50] <hallyn> meh
[14:23] <rharper> hallyn: just wait till you start allocating io-threads to each of your devices =)
[14:30] <hallyn> rharper: i've always assumed this was all jsut an attempt to force us to use libvirt :)
[14:35] <rharper> hallyn: heh, no, that was when they stopped allowing folks to query features via the cli; wanted folks to use qmp to "discover" features;
[14:36] <rharper> https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1716028
[14:36] <ubottu> Launchpad bug 1716028 in libvirt (Ubuntu) "qemu 2.10 locks images with no feature flag" [Medium,Fix released]
[14:36] <hallyn> half-lol :)
=== Tornevall is now known as Guest64769
[17:19] <hallyn> rharper: so - all that, and discard is not working for me!  hm.
[17:29] <hallyn> ok, so i see - it doesn't shrink the file of hte qcow file, but it re-uses the discarded space (so create 1G, rm 1G, create 1g  doesn't take up 2 G)
[17:29] <hallyn> "could be worse"
[17:30] <sarnold> it could also be better.. if those bits on disk really aren't needed it'd be nice to zero em out for rebalancing :(
[17:40] <lordcirth> sarnold, as a one-off, you can use qemu-img convert to produce a shrunk file
[17:41] <sarnold> lordcirth: yeah.. bummer that it takes that kind of effort though :( if the vm actually went to the effort to issue a discard call, that information is already sitting there..
[17:52] <rharper> hallyn: what's your cli look like ?
[17:53] <hallyn> kvm -drive if=none,id=hd,file=x.qcow2,format=qcow2 -device virtio-scsi-pci,id=scsi --enable-kvm -device scsi-hd,drive=hd  -m 4096 -drive if=none,id=hd2,file=y.qcow2,format=qcow2 -device scsi-hd,drive=hd2
[17:53] <hallyn> rharper: ^
[17:56] <compdoc> I started using raw
[17:57] <rharper>  you need:  -drive if=none,id-hd,file=x.qcow2,format=qcow2,discard=unmap,detect-zeroes=unmap
[17:57] <rharper> and you're running fstrim in guest and checking on host afterward ?
[17:58] <rharper> well, at least the discard=unmap; I've not yet tested the detect-zeroes either, but I suspect that may be helpful for guests which zero block space
[18:01] <hallyn> i thought about detect-zeroes, but my reading of the manpages suggested that all of that would default to what i wanted
[18:01] <hallyn> oh, maybe not - maybe htat was seen as too much perf impact?
[18:01] <hallyn> yeah, running fstrim in guest then checking host
[18:07] <rharper> hallyn: which version of qemu ?
[18:12] <rharper> hallyn: I would try being explicit; I see some references to enabling discard by default, but the man pages don't indicate the default discard mode on -blockdev or -drive, or if the defaults are the same;  =(
[18:32] <hallyn> rharper: QEMU emulator version 4.0.0 (Debian 1:4.0+dfsg-0ubuntu5)
[18:33] <hallyn> i added the discard and zeroing options, same behavior
[18:33] <hallyn> maybe i needed to wait longer? :)  that would make sense
[18:34] <hallyn> i assume detecting zeroes takes some time
[18:41] <rharper> hallyn: I don't think so;  it should be immediate, fstrim in guest to host should result in a  punchole syscall to the file on the host ;  have to tried raw vs qcow2?
[18:43] <hallyn> no
[18:44] <hallyn> i suppose this could be qcow2 bogosity
[18:46]  * rharper tries it out locally 
[18:54] <hallyn> rharper: yes!  raw works
[18:54] <hallyn> at least, with simple ext4, lemme try lvm now
[19:02] <hallyn> rharper: yeah, even lvm thinpools shrink that way.
[19:03] <hallyn> whodathunk raw format works better for shrinking size than qcow2 :)
[19:03] <hallyn> (we all know - you would :)
[19:03] <rharper> hallyn: it's working for me (xenial qemu 2.x) on both qcow2 and raw;
[19:03] <hallyn> thanks rharper
[19:03] <hallyn> hm
[19:03] <rharper> ext4 on both filesystems
[19:03] <rharper> lemme repeat on qemu 4.x
[19:03] <hallyn> qcow2 doesn't work for me, but that's probably ok
[19:04] <rharper> how is your qcow2 built ? base image or layered with a backing file ?
[19:04] <hallyn> just a base qemu-img create -f qcow2 x.qcow2 10G
[19:04] <rharper> yeah
[19:04] <rharper> same here in my tests
[19:20] <rharper> hallyn: so, on qemu 4.0 I see almost *no* trim in the qcow2;  so I suspect there's some additional flags that need set  on the qcow2 -drive parameter
[19:20] <rharper> so that confirms what you see
[21:41] <hallyn> in some circles that would be called a regression :)
[22:55] <keithzg[m]> Hmm, one VM at work (running on KVM) now fails to boot with 4.15.0-58-generic. Still fine with 4.15.0-38-generic, and even more weirdly, other 32-bit VMs using 4.15.0-58-generic boot just fine on the same host.