[07:13] Good morning [07:13] hi lordievader [07:16] Hey cpaelzer How are you? [07:17] good enough for a monday :-) [07:17] and you? [07:17] Hahaha. I'm doing allright. [10:29] coreycb: nova and glance b2's uploaded - doing heat and neutron next [11:10] good morning [11:16] morning ahasenack [11:16] hello Nafallo [11:45] coreycb: cinder done; neutron failing a test and heat generally being awkward [11:45] coreycb: doing keystone [12:09] coreycb: keystone done; I'm going todo a snapshot of aodh if I can make it work [12:24] coreycb: barbican done [12:33] jamespage: sounds good, i'll start in a bit [12:48] coreycb: neutron done [13:53] jamespage: getting started with horizon [13:53] coreycb: ok working through the neutron-*'s now [13:55] jamespage: are you using a bileto ppa? [14:07] coreycb: no [14:07] just local sbuild [14:08] coreycb: I've done a tweak to the watch file in my uploaded to tie the package to a specific series; dunno what you think about that [14:08] makes gbp import-orig --uscan dtrt [14:09] jamespage: ok. i'm going to use https://bileto.ubuntu.com/#/ticket/3076. you're welcome to use it if you want. [14:09] jamespage: ok i'll tie that in as well to the watch files [14:11] jamespage: i usually specify the version on uscan so i'm indifferent but i think this is fine [14:51] I was recommended to ask this here: "Can anyone explain why this part of interfaces config doesn't add the routes i'm asking it to add? https://gist.github.com/Lillecarl/d152e0f93405005ea2fd451f33645968" <- Running Ubuntu 16.04 server [14:55] LilleCarl: those additional routes shouldn't be needed as they are relying on the default gateway anyways [14:56] @sdeziel Well actually the device's got one direct wan connection and one lan connection [14:56] It's acting as a VPN server-ish [14:57] So the default route goes over ens160 [14:57] LilleCarl: then I'd remove the "gateway 172.30.30.1" line then as this one too tries to add a default gateway [14:58] I'll do that [14:58] LilleCarl: then if the "up" command still do not accomplish what you wanted, I'd suggest running them by hand and see if /sbin/ip spits an error on them [14:59] sdeziel: Now the up commands worked [14:59] Isn't that weird? [14:59] Also, thanks! :) [15:00] LilleCarl: I don't know. Was br0 coming up at all before? Cause 2 default gateways could have prevent the second one (the one from br0) from working [15:00] in other words, I don't know if ifup would capitulate on the "gateway" clause failing to apply [15:00] sdeziel: It was functioning indeed, and "ip link" showed it as up [15:01] But yeah that explains it, trying to override default gw could fail the up scripts [15:01] LilleCarl: yeah but that's one level too low ;). I guess the question should have been: did br0 had an IP configured? [15:02] sdeziel: Wierdly enough it did, i was pinging it locally. I guess it's weird undefined behaviour [15:03] LilleCarl: interesting problem :) [15:03] Indeed, caused by stupid human as usually though ;) [15:50] Good {morning,afternoon,evening}. I'm still trying to get an external USB drive passed through to my KVM VM from the host. I tried going through virt-manager, and I also tried creating an XML file and attaching it. I've rebooted the host and guest many times. I also tried USB2/USB3 and switching the chipset. Has anyone been successful with this? (Ubuntu Server 16.04) [15:53] jlacroix: yes I've doen it - did you check out the related known apparmor issues [15:53] jlacroix: TL;DR while you are trying to attach in a 2nd window run "sudo dmesg -w" [15:53] cpaelzer I have seen that during google searching. I flat-out disabled apparmor on the host and guest, that didn't solve it [15:53] likely you see apparmor denies, and likely the bugs I linked have the fixes that you can add to your conffiles [15:54] Should I run the dmesg on the host or guest? [15:54] well if you disabled apparmor fully then this isn't the issue :-) [15:54] jlacroix: I recommend to track two things then [15:55] 1. in a 2nd console dmesg -w - what happens on the try to atatch [15:55] Are these apparmor issues with the guest or the host? Or both? When reading I wasn't sure if they were referring to the guest or host when talking about apparmor [15:55] 2. in 3rd console track /var/log/libvirt/qemu/.log - is there an issue reported [15:55] jlacroix: the issues were the host being more on the secure than on the comfortable side [15:55] jlacroix: this needed some work/research to sort out rules that work but are not considered insecure [15:56] but demsg will show you if this still is an issue [15:56] coreycb: I believe automation tricked you when picking 1710019 into cloud archive [15:58] coreycb: there is (a lot) detail in the bug - TL;DR this was cancelled from -proposed for zesty but picked for Ocata now [15:59] cpaelzer: got it, thanks. i'll update the bug. [15:59] Thanks cpaelzer, I'll try that out when I get home. I'm remotely connected via SSH right now and so far I don't see anything in the logs on the host. But perhaps I will when I disconnect and reconnect the drive. But as of right now there is nothing in the log file and it has not cycled [16:01] I'm assuming the usb disk would show up with lsusb or lsblk if successfully passed through [16:04] cpaelzer: are you +1 to reverting that then? [16:04] coreycb: well we reverted it in proposed until dannf had the chance to sort out the details [16:04] coreycb: so that particular change on the actual release did never show up [16:05] coreycb: thereby yes I'm +1 to also pull it out of UCA for now [16:05] cpaelzer: ack [16:05] jlacroix: give it a try and let us know [16:06] jlacroix: you could pastebin both logs if you are unsure what they show you [16:08] cpaelzer the log for the VM in question contains no errors. The dmesg contains nothing regarding the usb drive, other than "new usb device found" [16:09] jlacroix: is this the demsg of the host? [16:09] cpaelzer: yes, the host [16:10] well that means it was atatched (or tried to) and comes back to the host [16:10] that is why it is seeing it as new device [16:10] hmm [16:10] and what does virsh attach ... tell you [16:10] Honestly the "new usb device found" could just have been when the host was booted [16:10] it must say failed "foo" then right? [16:11] jlacroix: that is why I meand sudo dmesg -w [16:11] that follows [16:11] so you can add a few empty lines with enter [16:11] then do the action [16:11] and report only what appears as new events [16:12] jlacroix: the same works on the guest log file if you use "tail -f" on it [16:16] When I run "virsh attach-device" it says "device attached successfully" [16:25] jlacroix: then doesn#t that sound good to you? [16:25] jlacroix: so the host thinks all is fine [16:25] jlacroix: you can now do the same with dmesg but in the guest [16:25] cpaelzer, yes that sounds great. But lusb, lsblk, and fdisk -l show no extra disks [16:26] jlacroix: when you detach/attach you should see the device appearing [16:26] do you? [16:26] I do not [16:27] you do not see anything in guest dmesg when you do so? [16:27] Correct, nothing [16:27] weird [16:27] sorry jlacroix I never had that combination [16:27] unfortunately all you do is what I do, so your steps are not valid to reproduce on my end [16:28] jlacroix: could you try various USB devices and check if all behave that way? [16:28] Yes, I can try that when I get home. I don't have physical access until this evening [16:31] jlacroix: The guest OS needs the PCI hotplug drivers too; acpiphp and pci_hotplug usually [16:32] jlacroix: I saw similar issues with both raw PCI devices and USB devices with minimal 'cloud' kernels [16:32] Thanks I'll try that now [16:33] as anyone been able to run memtest86+ (or any other mem-test) on a UEFI machine? [16:33] TJ I don't see those packages available [16:34] I do have acpid [16:35] They're kernel modules [16:38] Thanks for the response, but those modules are there. [16:39] sdeziel: as far as I recall it doesn't support UEFI since it's a 16-bit executable [16:39] jlacroix: are they loaded? [16:39] $ grep -A3 EFI /etc/grub.d/20_memtest86+ [16:39] # We need 16-bit boot, which isn't available on EFI. [16:39] if [ -d /sys/firmware/efi ]; then [16:39] exit 0 [16:40] TJ-: indeed, thanks. I'm going to try with the upstream provided ISO for now [16:40] TJ: I'm not really sure, they are in the kernel config marked "y", I think that means compiled in and not module if I'm not mistaken [16:41] jlacroix: yes, that is correct. So the guest is a 'fat' bare-metal kernel, not one designed for virtual machines/'cloud' ? [16:41] TJ: Correct. It was installed using the ubuntu-server ISO and not ubuntu-minimal or anything weird [16:41] jlacroix: in the guest does "lsusb" show USB hub(s)? [16:42] It does, it shows four of them [16:42] jlacroix: also, is the device you're attaching a mass storage device? sometimes it needs "usb_storage" module manually loading [16:43] TJ: The disk I'm attaching is a USB hard disk, no hub between them [16:43] jlacroix: there has to be a hub [16:44] TJ: Sorry what I mean is, I didn't add one between them [16:44] jlacroix: OK, that's fine, the VM should have one already defined in its hardware description, and the kernel has default drivers for them [16:57] jlacroix: does 'virsh dumpxml' show the device with a "" node? [17:08] TJ: It does [17:08] TJ: Sorry, managed: no [17:21] jlacroix: for USB that is ignored so it doesn't affect things [17:24] jlacroix: one data-point. When the device is removed from the host and attached to the guest, the HOST dmesg/kern.log should show something like "usb 2-2: reset high-speed USB device number 6 using ehci-pci" [18:59] Thanks TJ and cpaelzer for all your help. I'll troubleshoot more this evening [19:09] it appears that my ubuntu server is not allowing connections when i connect via unlimited vpn (my vpn provider). any way to find out if certain ip's are blocked somehwo? i have already stopped the fail2ban service [19:53] arooni: what makes you think it's the server that's blocking it? [19:55] good question; on some services I wind up blocking entire VPN netblocks due to abuse from time to time [19:55] it could be your service provider has done the same [19:56] some tests: (1) do a traceroute through the VPN, compare it to how it looks without VPN; (2) ping through the VPN and without the VPN, do both get through?; (3) run "nc -l -vv -p 8000" on the server and connect to it through the VPN and without the VPN from your client by running "nc -vv IP_ADDRESS_OF_SERVER 8000"; both server and client should report that the connection is established. [20:02] sarn [20:02] sarnold: how do i test to see whether its the server or my hosting provider [20:02] oops liooks like tomreyn mentions it [20:03] i wish my networking knowledge was a bit better :) === lukasa_ is now known as lukasa === Kamilion|ZNC is now known as Kamilion === StoneTable is now known as aisrael === rfleming is now known as rfleming_