Re: [CentOS-virt] Xen CentOS 7.3 server + CentOS 7.3 VM fails to boot after CR updates (applied to VM)!

2017-09-01 Thread Kevin Stange 
On 09/01/2017 02:41 PM, Kevin Stange wrote:
> On 08/31/2017 07:50 AM, PJ Welsh wrote:
>> A recently created and fully functional CentOS 7.3 VM fails to boot
>> after applying CR updates:
> 
>> Server OS is CentOS 7.3 using Xen (no CR updates):
>> rpm -qa xen\*
>> xen-hypervisor-4.6.3-15.el7.x86_64
>> xen-4.6.3-15.el7.x86_64
>> xen-licenses-4.6.3-15.el7.x86_64
>> xen-libs-4.6.3-15.el7.x86_64
>> xen-runtime-4.6.3-15.el7.x86_64
>>
>> uname -a
>> Linux tsxen2.xx.com  4.9.39-29.el7.x86_64 #1 SMP
>> Fri Jul 21 15:09:00 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
>>
>> Sadly, the other issue is that the grub menu will not display for me to
>> select another kernel to see if it is just a kernel issue.
>>
>> The dracut prompt does not show any /dev/disk folder either.
>>
> 
> I'm seeing this as well.  My host is 4.9.44-29 and Xen 4.4.4-26 from
> testing repo, my guest is 3.10.0-693.1.1.  Guest boots fine with
> 514.26.2.  The kernel messages that appear to kick off the failure for
> me start with a page allocation failure.  It eventually reaches dracut
> failures due to systemd/udev not setting up properly, but I think the
> root is this:
> 

I created bugs for this issue (at least as I'm able to reproduce it):

https://bugs.centos.org/view.php?id=0013763
https://bugzilla.redhat.com/show_bug.cgi?id=1487754

Please add any extra information you might have to hopefully increase
the chance the problem gets fixed.

-- 
Kevin Stange
Chief Technology Officer
Steadfast | Managed Infrastructure, Datacenter and Cloud Services
800 S Wells, Suite 190 | Chicago, IL 60607
312.602.2689 X203 | Fax: 312.602.2688
ke...@steadfast.net | www.steadfast.net
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

Re: [CentOS-virt] Xen CentOS 7.3 server + CentOS 7.3 VM fails to boot after CR updates (applied to VM)!

2017-09-01 Thread Kevin Stange 
On 08/31/2017 07:50 AM, PJ Welsh wrote:
> A recently created and fully functional CentOS 7.3 VM fails to boot
> after applying CR updates:

> Server OS is CentOS 7.3 using Xen (no CR updates):
> rpm -qa xen\*
> xen-hypervisor-4.6.3-15.el7.x86_64
> xen-4.6.3-15.el7.x86_64
> xen-licenses-4.6.3-15.el7.x86_64
> xen-libs-4.6.3-15.el7.x86_64
> xen-runtime-4.6.3-15.el7.x86_64
> 
> uname -a
> Linux tsxen2.xx.com  4.9.39-29.el7.x86_64 #1 SMP
> Fri Jul 21 15:09:00 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
> 
> Sadly, the other issue is that the grub menu will not display for me to
> select another kernel to see if it is just a kernel issue.
> 
> The dracut prompt does not show any /dev/disk folder either.
> 

I'm seeing this as well.  My host is 4.9.44-29 and Xen 4.4.4-26 from
testing repo, my guest is 3.10.0-693.1.1.  Guest boots fine with
514.26.2.  The kernel messages that appear to kick off the failure for
me start with a page allocation failure.  It eventually reaches dracut
failures due to systemd/udev not setting up properly, but I think the
root is this:

[1.970630] [ cut here ]
[1.970651] WARNING: CPU: 2 PID: 225 at mm/vmalloc.c:131
vmap_page_range_noflush+0x2c1/0x350
[1.970660] Modules linked in:
[1.970668] CPU: 2 PID: 225 Comm: systemd-udevd Not tainted
3.10.0-693.1.1.el7.x86_64 #1
[1.970677]   8cddc75d 8803e8587bd8
816a3d91
[1.970688]  8803e8587c18 810879c8 0083811c14e8
8800066eb000
[1.970698]  0001 8803e86d6940 c000

[1.970708] Call Trace:
[1.970725]  [] dump_stack+0x19/0x1b
[1.970736]  [] __warn+0xd8/0x100
[1.970742]  [] warn_slowpath_null+0x1d/0x20
[1.970748]  [] vmap_page_range_noflush+0x2c1/0x350
[1.970758]  [] map_vm_area+0x2e/0x40
[1.970765]  [] __vmalloc_node_range+0x170/0x270
[1.970774]  [] ? module_alloc_update_bounds+0x14/0x70
[1.970781]  [] ? module_alloc_update_bounds+0x14/0x70
[1.970792]  [] module_alloc+0x73/0xd0
[1.970798]  [] ? module_alloc_update_bounds+0x14/0x70
[1.970804]  [] module_alloc_update_bounds+0x14/0x70
[1.970811]  [] load_module+0xb02/0x29e0
[1.970817]  [] ? vmap_page_range_noflush+0x257/0x350
[1.970823]  [] ? map_vm_area+0x2e/0x40
[1.970829]  [] ? __vmalloc_node_range+0x170/0x270
[1.970838]  [] ? SyS_init_module+0x99/0x110
[1.970846]  [] SyS_init_module+0xc5/0x110
[1.970856]  [] system_call_fastpath+0x16/0x1b
[1.970862] ---[ end trace 2117480876ed90d2 ]---
[1.970869] vmalloc: allocation failure, allocated 24576 of 28672 bytes
[1.970874] systemd-udevd: page allocation failure: order:0, mode:0xd2
[1.970883] CPU: 2 PID: 225 Comm: systemd-udevd Tainted: GW
      3.10.0-693.1.1.el7.x86_64 #1
[1.970894]  00d2 8cddc75d 8803e8587c48
816a3d91
[1.970910]  8803e8587cd8 81188810 8190ea38
8803e8587c68
[1.970923]  0018 8803e8587ce8 8803e8587c88
8cddc75d
[1.970939] Call Trace:
[1.970946]  [] dump_stack+0x19/0x1b
[1.970961]  [] warn_alloc_failed+0x110/0x180
[1.970971]  [] __vmalloc_node_range+0x234/0x270
[1.970981]  [] ? module_alloc_update_bounds+0x14/0x70
[1.970989]  [] ? module_alloc_update_bounds+0x14/0x70
[1.970999]  [] module_alloc+0x73/0xd0
[1.971031]  [] ? module_alloc_update_bounds+0x14/0x70
[1.971038]  [] module_alloc_update_bounds+0x14/0x70
[1.971046]  [] load_module+0xb02/0x29e0
[1.971052]  [] ? vmap_page_range_noflush+0x257/0x350
[1.971061]  [] ? map_vm_area+0x2e/0x40
[1.971067]  [] ? __vmalloc_node_range+0x170/0x270
[1.971075]  [] ? SyS_init_module+0x99/0x110
[1.971081]  [] SyS_init_module+0xc5/0x110
[1.971088]  [] system_call_fastpath+0x16/0x1b
[1.971094] Mem-Info:
[1.971103] active_anon:875 inactive_anon:2049 isolated_anon:0
[1.971103]  active_file:791 inactive_file:8841 isolated_file:0
[1.971103]  unevictable:0 dirty:0 writeback:0 unstable:0
[1.971103]  slab_reclaimable:1732 slab_unreclaimable:1629
[1.971103]  mapped:1464 shmem:2053 pagetables:480 bounce:0
[1.971103]  free:4065966 free_pcp:763 free_cma:0
[1.971131] Node 0 DMA free:15912kB min:12kB low:12kB high:16kB
active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB
unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15996kB
managed:15912kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB
slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB
pagetables:0kB unstable:0kB bounce:0kB free_pcp:0kB local_pcp:0kB
free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
[1.971217] lowmem_reserve[]: 0 4063 16028 16028
[1.971226] Node 0 DMA32 free:4156584kB min:4104kB low:5128kB
high:6156kB active_anon:952kB inactive_anon:1924kB active_file:0kB
inactive_file:0kB unevictable:0kB isolated(anon):0kB

Re: [CentOS-virt] change network settings of VM depending on logged in user(s)?

2017-09-01 Thread PJ Welsh 
I'm not a M$ expert, but I've seen enough GPO's to believe there is a way
to do it through Windows.
PJWelsh

On Fri, Sep 1, 2017 at 11:43 AM, hw  wrote:

>
> Hi,
>
> is there a way to disable internet access for a windoze 7 VM depending
> on which user(s) is/are logged in?
>
> It seems windoze 7 doesn´t really support this, especially when you want
> to disable internet access for the whole machine, so I´m wondering if
> there is a way to do this when the machine is a KVM-VM running on Centos.
>
> The whole VM should only have internet access when a particular user logs
> in, and preferably for only this particular user.
> ___
> CentOS-virt mailing list
> CentOS-virt@centos.org
> https://lists.centos.org/mailman/listinfo/centos-virt
>
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

[CentOS-virt] change network settings of VM depending on logged in user(s)?

2017-09-01 Thread hw 


Hi,

is there a way to disable internet access for a windoze 7 VM depending
on which user(s) is/are logged in?

It seems windoze 7 doesn´t really support this, especially when you want
to disable internet access for the whole machine, so I´m wondering if
there is a way to do this when the machine is a KVM-VM running on Centos.

The whole VM should only have internet access when a particular user logs
in, and preferably for only this particular user.
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

Re: [CentOS-virt] Status of reverted Linux patch "tty: Fix ldisc crash on reopened tty", Linux 4.9 kernel frequent crashes

2017-09-01 Thread Pasi Kärkkäinen 
On Thu, Aug 31, 2017 at 03:22:05PM +1000, Michael Neuling wrote:
> On Thu, 2017-08-31 at 06:36 +0200, Greg Kroah-Hartman wrote:
> > On Wed, Aug 30, 2017 at 11:10:14PM +0300, Pasi Kärkkäinen wrote:
> > > Hello everyone,
> > > 
> > > Recently Nathan March reported on centos-virt list he's getting frequent
> > > Linux kernel crashes with Linux 4.9 LTS kernel because of the missing 
> > > patch
> > > "tty: Fix ldisc crash on reopened tty".
> > 
> > Crashes with "normal" operation, or crashes when running a fuzzer or
> > other type of program?
> 
> For me it crashed on boot.
>

Nathan said he's getting the crashes at runtime, randomly, but often.

 
> > 
> > > The patch was already merged upstream here:
> > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i
> > > d=71472fa9c52b1da27663c275d416d8654b905f05
> > > 
> > > but then reverted here:
> > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i
> > > d=896d81fefe5d1919537db2c2150ab6384e4a6610
> > > 
> > > Nathan confirmed if he applies the patch from
> > > 71472fa9c52b1da27663c275d416d8654b905f05 to his Linux 4.9 LTS kernel the
> > > bug/problem goes away, so the patch (or similar fix) is still needed, at
> > > least for 4.9 LTS kernel.
> > > 
> > > 
> > > Mikulas reported he's able to trigger the same crash on Linux 4.10:
> > > https://www.spinics.net/lists/kernel/msg2440637.html
> > > https://lists.gt.net/linux/kernel/2664604?search_string=ldisc%20reopened;#26
> > > 64604
> > > 
> > > Michael Neuling reported he's able to trigger the bug on PowerPC:
> > > https://lkml.org/lkml/2017/3/10/1582
> > > 
> > > 
> > > So now the question is.. is anyone currently working on getting this patch
> > > fixed and applied upstream? I think one of the problems earlier was being
> > > able to reliable reproduce the crash.. Nathan says he's able to reproduce 
> > > it
> > > many times per week on his environment on x86_64.
> > 
> > I don't know of anyone working on it, want to do it yourself?
> 
> I'm not anymore. We found it was only triggered on a bogus CONFIG option
> combination.  Once we removed that, it no longer happened.
> 
> The underlying bug was still there though.
> 


Yep.. and the bug seems to trigger at runtime.



> Mikey


-- Pasi

___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt