virt May 2017

virt@lists.centos.org

12 participants
8 discussions

Crash in CentOS 7 kernel-3.10.0-514.16.1.el7.x86_64 in Xen PV mode
by Sarah Newman 24 Oct '17

24 Oct '17

I experienced a bug that is likely the same as https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1350373 . Commit b7dd0e350e0bd4c0fddcc9b8958342700b00b168 , which is supposed to fix it, doesn't appear in this kernel and doesn't apply cleanly either. Is there any point in trying to backport the patch? The backtrace is as follows: [ 32.304666] ------------[ cut here ]------------ [ 32.304679] kernel BUG at arch/x86/kernel/paravirt.c:252! [ 32.304683] invalid opcode: 0000 [#1] SMP [ 32.304687] Modules linked in: ip6t_rpfilter ipt_REJECT nf_reject_ipv4 ip6t_REJECT nf_reject_ipv6 xt_conntrack ip_set nfnetlink ebtable_nat ebtable_broute bridge stp llc ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter intel_powerclamp coretemp pcspkr ip_tables ext4 mbcache jbd2 xen_netfront xen_blkfront crc32c_intel [ 32.304734] CPU: 0 PID: 3901 Comm: dracut Not tainted 3.10.0-514.16.1.el7.x86_64 #1 [ 32.304739] task: ffff880002598000 ti: ffff88001b728000 task.ti: ffff88001b728000 [ 32.304743] RIP: e030:[<ffffffff8167eb81>] [<ffffffff8167eb81>] enter_lazy.part.0+0x4/0x6 [ 32.304755] RSP: e02b:ffff88001f803aa8 EFLAGS: 00010002 [ 32.304758] RAX: 0000000000000001 RBX: ffff88001eacd640 RCX: 00003ffffffff000 [ 32.304761] RDX: ffff880000000640 RSI: ffffc900000c8000 RDI: 0000000000000001 [ 32.304765] RBP: ffff88001f803aa8 R08: ffff88001f803b78 R09: ffffffff813d50f9 [ 32.304771] R10: ffff88001e801e00 R11: ffffea0000093dc0 R12: ffffc900000c9000 [ 32.304777] R13: ffffc900000c8000 R14: 0000000000000000 R15: ffff88001d150340 [ 32.304787] FS: 00007f64425b0740(0000) GS:ffff88001f800000(0000) knlGS:0000000000000000 [ 32.304796] CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b [ 32.304801] CR2: 00000000006de2c8 CR3: 000000001b405000 CR4: 0000000000002660 [ 32.304807] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 32.304813] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 32.304818] Stack: [ 32.304823] ffff88001f803ab8 ffffffff81061857 ffff88001f803b60 ffffffff811b1fe2 [ 32.304833] ffffc900000c8fff ffffc900000c9000 ffffffff819bac90 ffffc900000c8fff [ 32.304843] ffffc900000c9000 ffff88001eacb000 ffffffff810206b0 0000000000000000 [ 32.304854] Call Trace: [ 32.304858] <IRQ> [ 32.304861] [<ffffffff81061857>] paravirt_enter_lazy_mmu+0x27/0x30 [ 32.304879] [<ffffffff811b1fe2>] apply_to_page_range+0x282/0x460 [ 32.304888] [<ffffffff810206b0>] ? map_pte_fn+0x60/0x60 [ 32.304894] [<ffffffff810207fb>] arch_gnttab_map_status+0x3b/0x70 [ 32.304904] [<ffffffff813d5176>] gnttab_map_frames_v2+0xd6/0x150 [ 32.304910] [<ffffffff813d5291>] gnttab_map+0xa1/0x140 [ 32.304917] [<ffffffff813d5430>] get_free_entries+0x100/0x2e0 [ 32.304923] [<ffffffff813d56d5>] gnttab_alloc_grant_references+0x15/0x30 [ 32.304933] [<ffffffffa000bd4f>] do_blkif_request+0x6bf/0x8a0 [xen_blkfront] [ 32.304945] [<ffffffff812eb0e2>] ? __freed_request+0x92/0xa0 [ 32.304951] [<ffffffff812eb6e3>] __blk_run_queue+0x33/0x40 [ 32.304957] [<ffffffff812eb719>] blk_start_queue+0x29/0x40 [ 32.304964] [<ffffffffa000bf51>] kick_pending_request_queues+0x21/0x30 [xen_blkfront] [ 32.304975] [<ffffffffa000c6ce>] blkif_interrupt+0x76e/0x820 [xen_blkfront] [ 32.304986] [<ffffffff811dcc8b>] ? kmem_cache_free+0x1bb/0x1f0 [ 32.304995] [<ffffffff8113079e>] handle_irq_event_percpu+0x3e/0x1e0 [ 32.305003] [<ffffffff8113097d>] handle_irq_event+0x3d/0x60 [ 32.305004] [<ffffffff81133647>] handle_edge_irq+0x77/0x130 [ 32.305004] [<ffffffff813d6217>] __xen_evtchn_do_upcall+0x227/0x350 [ 32.305004] [<ffffffff813d83c3>] xen_evtchn_do_upcall+0x33/0x50 [ 32.305004] [<ffffffff81698c7e>] xen_do_hypervisor_callback+0x1e/0x30 [ 32.305004] <EOI> [ 32.305004] [<ffffffff811af916>] ? copy_pte_range+0x2b6/0x5a0 [ 32.305004] [<ffffffff811af8e6>] ? copy_pte_range+0x286/0x5a0 [ 32.305004] [<ffffffff811b24d2>] ? copy_page_range+0x312/0x490 [ 32.305004] [<ffffffff81083012>] ? dup_mm+0x362/0x680 [ 32.305004] [<ffffffff810847ae>] ? copy_process+0x144e/0x1960 [ 32.305004] [<ffffffff81084e71>] ? do_fork+0x91/0x2c0 [ 32.305004] [<ffffffff81085126>] ? SyS_clone+0x16/0x20 [ 32.305004] [<ffffffff816974d9>] ? stub_clone+0x69/0x90 [ 32.305004] [<ffffffff81697189>] ? system_call_fastpath+0x16/0x1b [ 32.305004] Code: 20 e9 2f ff ff ff 44 89 fa 44 89 ee 48 c7 c7 10 45 8c 81 31 c0 e8 9d 14 00 00 58 5a 5b 41 5c 41 5d 41 5e 41 5f 5d c3 55 48 89 e5 <0f> 0b 66 66 66 66 90 55 48 89 e5 0f 0b 55 48 89 e5 0f 0b 55 48 [ 32.305004] RIP [<ffffffff8167eb81>] enter_lazy.part.0+0x4/0x6 [ 32.305004] RSP <ffff88001f803aa8> [ 32.305004] ---[ end trace 49f67f0d85e1ac69 ]--- [ 32.305004] Kernel panic - not syncing: Fatal exception in interrupt Thanks, Sarah

3 6

Patch for SELinux on Xen 4.7+
by George Dunlap 30 May '17

30 May '17

Sarah / Anthony, Attached is the patch I mentioned in the meeting today. -George

1 0

lvm cache + qemu-kvm stops working after about 20GB of writes
by Richard Landsman - Rimote 26 May '17

26 May '17

Hello, I would really appreciate some help/guidance with this problem. First of all sorry for the long message. I would file a bug, but do not know if it is my fault, dm-cache, qemu or (probably) a combination of both. And i can imagine some of you have this setup up and running without problems (or maybe you think it works, just like i did, but it does not): PROBLEM LVM cache writeback stops working as expected after a while with a qemu-kvm VM. A 100% working setup would be the holy grail in my opinion... and the performance of KVM/qemu is great i must say in the beginning. DESCRIPTION When using software RAID 1 (2x HDD) + software RAID 1 (2xSSD) and create a cached LV out of them, the VM performs initially great (at least 40.000 IOPS on 4k rand read/write)! But then after a while (and a lot of random IO, ca 10 - 20 G) it effectively turns in to a writethrough cache although there's much space left on the cachedlv. When working as expected on KVM host all writes go to SSDs iostat -x -m 2 Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util sda 0.00 324.50 0.00 22.00 0.00 14.94 1390.57 1.90 86.39 0.00 86.39 5.32 11.70 sdb 0.00 324.50 0.00 22.00 0.00 14.94 1390.57 2.03 92.45 0.00 92.45 5.48 12.05 sdc 0.00 3932.00 0.00 *2191.50* 0.00 *270.07* 252.39 37.83 17.55 0.00 17.55 0.36 *78.05* sdd 0.00 3932.00 0.00 *2197.50 * 0.00 *271.01 * 252.57 38.96 18.14 0.00 18.14 0.36 *78.95* When not working as expected on KVM host all writes go through the SSD on to the HDDs (effectively disabling writeback so it becomes a writethrough) Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util sda 0.00 7.00 234.50 *173.50 * 0.92 *1.95* 14.38 29.27 71.27 111.89 16.37 2.45 *100.00* sdb 0.00 3.50 212.00 *177.50 * 0.83 *1.95* 14.60 35.58 91.24 143.00 29.42 2.57*100.10* sdc 2.50 0.00 566.00 *199.00 * 2.69 0.78 9.28 0.08 0.11 0.13 0.04 0.10 *7.70* sdd 1.50 0.00 76.00 *199.00* 0.65 0.78 10.66 0.02 0.07 0.16 0.04 0.07 *1.85* Stuff i've checked/tried: - The data in the cached LV has then not exceeded even half of the space, so this should not happen. It even happens when only 20% of cachedata is used. - It seems to be triggerd most of the time when %cpy/sync column of `lvs -a` is about 30%. But this is not always the case! - changing the cachepolicy from cleaner to smq, wait (check flush ready with lvs -a) and then back to smq seems to help /sometimes/! But not always... lvchange --cachepolicy cleaner /dev/mapper/XXX-cachedlv lvs -a lvchange --cachepolicy smq /dev/mapper/XXX-cachedlv - *when mounting the LV inside the host this does not seem to happen!!* So it looks like a qemu-kvm / dm-cache combination issue. Only difference is that inside host i do mkfs in stead of LVM inside VM (so could be LVM inside VM on top of LVM on KVM host problem too? small chance probably because the first 10 - 20GB it works great!) - tried disabling Selinux, upgrading to newest kernels (elrepo ml and lt), played around with dirty_cache thingeys like proc/sys/vm/dirty_writeback_centisecs /proc/sys/vm/dirty_expire_centisecs cat /proc/sys/vm/dirty_ratio , and migration threashold of dmsetup, and other probably non important stuff like vm.dirty_bytes - when in "slow state" the systems kworkers are exessively using IO (10 - 20 MB per kworker process). This seems to be the writeback process (CPY%Sync) because the cache wants to flush to HDD. But the strange thing is that after a good sync (0% left), the disk may become slow again after a few MBs of data. A reboot sometimes helps. - have tried iothreads, virtio-scsi, vcpu driver setting on virtio-scsi controller, cachesettings, disk shedulers etc. Nothing helped. - the new samsung 950 PRO SSDs have HPA enabled (30%!!), i have AMD FX(tm)-8350, 16G RAM It feels like the lvm cache has a threshold (about 20G of data that is dirty) and that is stops allowing the qemu-kvm process to use writeback caching (the root uses inside the host seems to not have this limitation). It starts flushing, but only to a certain point. After a few MBs of data it is right back in the slow spot again. Only solution is waiting for a long time (independant of CPY%SYNC) or sometimes change cachepolicy and force flush. This prevents for me the production use of this system. But it's so promising, so I hope somebody can help. desired state: Doing the FIO test (described in section reproduce) repeatedly should keep being fast till cachedlv is more or less full. If resyncing back to disc causes this degradation, it should actually flush it fully within a reasonable time and give opportunity to write fast again up to a given threshold. It now seems like a one time use cache that only uses a fraction of the SSD and is useless/very unstable afterwards. REPRODUCE 1. Install newest CentOS 7 on software RAID 1 HDDs with LVM. Keep a lot of space for the LVM cache (no /home)! So make the VG as large as possible during anaconda partitioning. 2. once installed and booted in to the system, install qemu-kvm yum install -y centos-release-qemu-ev yum install -y qemu-kvm-ev libvirt bridge-utils net-tools # disbale ksm (probably not important / needed) systemctl disable ksm systemctl disable ksmtuned 3. create LVM cache #set some variables and create a raid1 array with the two SSDs VGBASE= && ssddevice1=/dev/sdX1 && ssddevice2=/dev/sdX1 && hddraiddevice=/dev/mdXXX && ssdraiddevice=/dev/mdXXX && mdadm --create --verbose ${ssdraiddevice} --level=mirror --bitmap=none --raid-devices=2 ${ssddevice1} ${ssddevice2} # create PV and extend VG pvcreate ${ssdraiddevice} && vgextend ${VGBASE} ${ssdraiddevice} # create slow LV on HDDs (use max space left if you want) pvdisplay ${hddraiddevice} lvcreate -lXXXX -n cachedlv ${VGBASE} ${hddraiddevice} # create the meta and data: for testing purposes I keep about 20G of the SSD for a uncached lv. To rule out it is not the SSD. lvcreate -l XX -n testssd ${VGBASE} ${ssdraiddevice} #The rest can be used as cachedata/metadata. pvdisplay ${ssdraiddevice} # about 1/1000 of the space you have left on the SSD for the meta (minimum of 4) lvcreate -l X -n cachemeta ${VGBASE} ${ssdraiddevice} # the rest can be used as cachedata lvcreate -l XXX -n cachedata ${VGBASE} ${ssdraiddevice} # convert/combine pools so cachedlv is actually cached lvconvert --type cache-pool --cachemode writeback --poolmetadata ${VGBASE}/cachemeta ${VGBASE}/cachedata lvconvert --type cache --cachepool ${VGBASE}/cachedata ${VGBASE}/cachedlv # my system now looks like (VG is called cl, default of installer) [root@localhost ~]# lvs -a LV VG Attr LSize Pool Origin [cachedata] cl Cwi---C--- 97.66g * [cachedata_cdata] cl Cwi-ao---- 97.66g ** ** [cachedata_cmeta] cl ewi-ao---- 100.00m * * cachedlv cl Cwi-aoC--- 1.75t [cachedata] [cachedlv_corig] * [cachedlv_corig] cl owi-aoC--- 1.75t [lvol0_pmspare] cl ewi------- 100.00m root cl -wi-ao---- 46.56g swap cl -wi-ao---- 14.96g * testssd cl -wi-a----- 45.47g *[root@localhost ~]#lsblk* * NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sdd 8:48 0 163G 0 disk └─sdd1 8:49 0 163G 0 part └─md128 9:128 0 162.9G 0 raid1 ├─cl-cachedata_cmeta 253:4 0 100M 0 lvm │ └─cl-cachedlv 253:6 0 1.8T 0 lvm ├─cl-testssd 253:2 0 45.5G 0 lvm └─cl-cachedata_cdata 253:3 0 97.7G 0 lvm └─cl-cachedlv 253:6 0 1.8T 0 lvm sdb 8:16 0 1.8T 0 disk ├─sdb2 8:18 0 1.8T 0 part │ └─md127 9:127 0 1.8T 0 raid1 │ ├─cl-swap 253:1 0 15G 0 lvm [SWAP] │ ├─cl-root 253:0 0 46.6G 0 lvm / │ └─cl-cachedlv_corig 253:5 0 1.8T 0 lvm │ └─cl-cachedlv 253:6 0 1.8T 0 lvm └─sdb1 8:17 0 954M 0 part └─md126 9:126 0 954M 0 raid1 /boot sdc 8:32 0 163G 0 disk └─sdc1 8:33 0 163G 0 part └─md128 9:128 0 162.9G 0 raid1 ├─cl-cachedata_cmeta 253:4 0 100M 0 lvm │ └─cl-cachedlv 253:6 0 1.8T 0 lvm ├─cl-testssd 253:2 0 45.5G 0 lvm └─cl-cachedata_cdata 253:3 0 97.7G 0 lvm └─cl-cachedlv 253:6 0 1.8T 0 lvm sda 8:0 0 1.8T 0 disk ├─sda2 8:2 0 1.8T 0 part │ └─md127 9:127 0 1.8T 0 raid1 │ ├─cl-swap 253:1 0 15G 0 lvm [SWAP] │ ├─cl-root 253:0 0 46.6G 0 lvm / │ └─cl-cachedlv_corig 253:5 0 1.8T 0 lvm │ └─cl-cachedlv 253:6 0 1.8T 0 lvm └─sda1 8:1 0 954M 0 part └─md126 9:126 0 954M 0 raid1 /boot # now create vm wget http://ftp.tudelft.nl/centos.org/6/isos/x86_64/CentOS-6.9-x86_64-minimal.iso -P /home/ DISK=/dev/mapper/XXXX-cachedlv # watch out, my netsetup uses a custom bridge/network in the following command. Please replace with what you normally use. virt-install -n CentOS1 -r 12000 --os-variant=centos6.7 --vcpus 7 --disk path=${DISK},cache=none,bus=virtio --network bridge=pubbr,model=virtio --cdrom /home/CentOS-6.9-x86_64-minimal.iso --graphics vnc,port=5998,listen=0.0.0.0 --cpu host # now connect with client PC to qemu virt-viewer --connect=qemu+ssh://root@192.168.0.XXX/system --name CentOS1 And install everything on the single vda disc with LVM (i use defaults in anaconda, but remove the large /home to prevent SSD beeing over used). After install and reboot log in to VM and yum install epel-release -y && yum install screen fio htop -y and then run disk test: fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test *--filename=test* --bs=4k --iodepth=64 --size=4G --readwrite=randrw --rwmixread=75 then *keep repeating *but *change the filename* attribute so it does not use the same blocks over and over again. In the beginning the performance is great!! Wow, very impressive 150MB/s 4k random r/w (close to bare metal, about 20% - 30% loss). But after a few (usually about 4 or 5) runs (always changing the filename, but not overfilling the FS, it drops to about 10 MBs/sec. normal/in the beginning read : io=3073.2MB, bw=183085KB/s, *iops=45771* , runt= 17188msec write: io=1022.1MB, bw=60940KB/s, *iops=15235* , runt= 17188msec but then read : io=3073.2MB, bw=183085KB/s, *iops=**2904* , runt= 17188msec write: io=1022.1MB, bw=60940KB/s, *iops=1751* , runt= 17188msec or even worse up to the point that it is actually the HDD that is written to (about 500 iops). P.S. when a test is/was slow, that means it is on the HDDs. So even when fixing the problem (sometimes just by waiting), that specific file will keep being slow when redoing the test till its promoted to the lvm cache (takes a lot of reads I think). And once on the SSD it sometimes keeps beeing fast, although a new testfile will be slow. So I really recommend changing the testfile all the time when trying to see if a change in speed has occurred. -- Met vriendelijke groet, Richard Landsman http://rimote.nl T: +31 (0)50 - 763 04 07 (ma-vr 9:00 tot 18:00) 24/7 bij storingen: +31 (0)6 - 4388 7949 @RimoteSaS (Twitter Serviceberichten/security updates)

2 4

libxl: fix param assignment in domainGetSchedulerParameters
by Yuriy Kohut 26 May '17

26 May '17

Hello, Do you have any plans to include the https://www.redhat.com/archives/libvir-list/2016-September/msg01284.html <https://www.redhat.com/archives/libvir-list/2016-September/msg01284.html> patch into libvirt version 2.2.0, shipped for the RHEL/CentOS 7.x and Xen 4.6.x ? Thanks --- Yura

1 0

xen-4.6.3-14.el6.x86_64
by Piotr Gackiewicz 22 May '17

22 May '17

Hello, xen-4.6.3-14.el6.x86_64 is in testing since 5th of May. Isn't it production ready yet? It fixes 3 XSAs... Regards, -- Piotr Gackiewicz Intertele S.A. - operator systemów ITL.PL i DOMENY.ITL.PL al. T. Rejtana 10, 35-310 Rzeszów TEL: +48 17 8507580, FAX: +48 17 8520275 http://www.itl.pl - niezawodne usługi hostingowe http://domeny.itl.pl - tanie domeny internetowe http://www.intertele.pl

2 1

What is the purpose setting console=hvc0 in the dom0 grub config?
by Jerry 17 May '17

17 May '17

Howdy, I recently went through a frustrating experience trying to get Xen 4 running on a CentOS 7 system. After a fresh install, fully updating the system, rebooting, then trying to install Xen4CentOS it would fail to boot into the 4.9 kernel, sitting there with a blinking cursor indefinitely. I thought it was a failure with grub, but it turns out this was set in the grub config: GRUB_CMDLINE_LINUX_XEN_REPLACE_DEFAULT="console=hvc0 ..." So the kernel was loading successfully, but it was failing boot properly (hanging because it couldn't find the / file system, but that's a different story). Boot messages were not being displayed on my console because of the console=hvc0 setting, hampering the troubleshooting process. What is the purpose of setting console=hvc0? I removed it so I could trouble shoot this problem, but I didn't re-add it and the system booted fine, Xen is working. Is there something that depends on this? I always disable "rhgb quiet" on a fresh install because I don't like boot messages being hidden from me, and now this other thing does it. I like details, I need the details, don't hide them from me. Thanks, Jerry

6 14

4.9 kernel fails to boot because it didn't have the mpt3sas module
by Jerry 17 May '17

17 May '17

Howdy, I hit a snag trying to install Xen4CentOS on a Supermicro based system (X9DRD-7LN4F with the Broadcom/LSI 2308 chipset). I spent a few hours on this today, I'm posting this here in case it helps anyone else and saves them the frustration I dealt with. On this system I did a fresh install of CentOS 7, updated it, rebooted it, then installed Xen. The system was booting fine using the latest 3.10 kernel (3.10.0-514.16 at the time of writing this). But, when it tried to boot the kernel for Xen (4.9.25-27) it failed to do so. On first boot all it showed was a blinking cursor after grub attempted to boot the 4.9 kernel, and it sat there indefinitely. After some digging around I removed the "console=hvc0" setting /etc/default/grub, ran grub2-mkconfig, and tried booting 4.9 again. This time it actually showed messages, leading up to this: [ 186.550326] dracut-initqueue[542]: Warning: dracut-iniqueue timeout - starting timeout scripts [ 186.570380] dracut-initqueue[542]: Warning: dracut-iniqueue timeout - starting timeout scripts [ 187.120156] dracut-initqueue[542]: Warning: dracut-iniqueue timeout - starting timeout scripts [ 188.633714] dracut-initqueue[542]: Warning: dracut-iniqueue timeout - starting timeout scripts [ 189.102305] dracut-initqueue[542]: Warning: dracut-iniqueue timeout - starting timeout scripts [...] [ OK ] Started dracut initqueue hook [ OK ] Reached target Remote File Systems (Pre). [ OK ] Reached target Remote File Systems. [ ***] A start job is running for dev-disk...device (3min 35s / no limit) I let this run for a while to see if anything changed (needed to turn my attention elsewhere). After a couple of hours it was still in the same place. This last line was confusing: [ ***] A start job is running for dev-disk...device (3min 35s / no limit) Had the console not truncated that line and instead just wrapped the full message so I could see it I would have been a much happier person. Turns out dracut was unable to mount the root file system. So I went back into the 3.10 kernel again to see if the mpt2sas or mpt3sas driver was in its initramfs file... and it wasn't: $ sudo lsinitrd -k 4.9.25-27.el7.x86_64 | grep mpt -rw-r--r-- 1 root root 0 May 16 12:39 etc/fstab.empty -rw-r--r-- 1 root root 22 Nov 5 2016 usr/lib/kbd/unimaps/empty.uni For comparison: $ sudo lsinitrd -k 3.10.0-514.16.1.el7.x86_64 | grep mpt -rw-r--r-- 1 root root 0 May 16 04:37 etc/fstab.empty -rw-r--r-- 1 root root 22 Nov 5 2016 usr/lib/kbd/unimaps/empty.uni drwxr-xr-x 2 root root 0 May 16 04:37 usr/lib/modules/3.10.0-514.16.1.el7.x86_64/kernel/drivers/scsi/mpt3sas -rw-r--r-- 1 root root 379021 Apr 12 08:51 usr/lib/modules/3.10.0-514.16.1.el7.x86_64/kernel/drivers/scsi/mpt3sas/mpt2sas.ko So I added it: $ sudo dracut --force --add-drivers mpt3sas --kver=4.9.25-27.el7.x86_64 $ sudo lsinitrd -k 4.9.25-27.el7.x86_64 | grep mpt Arguments: --force --add-drivers 'mpt3sas' --kver '4.9.25-27.el7.x86_64' -rw-r--r-- 1 root root 0 May 16 12:57 etc/fstab.empty -rw-r--r-- 1 root root 22 Nov 5 2016 usr/lib/kbd/unimaps/empty.uni drwxr-xr-x 2 root root 0 May 16 12:57 usr/lib/modules/4.9.25-27.el7.x86_64/kernel/drivers/scsi/mpt3sas -rwxr--r-- 1 root root 374152 May 16 12:57 usr/lib/modules/4.9.25-27.el7.x86_64/kernel/drivers/scsi/mpt3sas/mpt3sas.ko After this I was able to get the 4.9 kernel to boot and Xen is now working. Jerry

2 4

centos-virt IRC meetings
by Sarah Newman 17 May '17

17 May '17

Hi, We were hoping to attend an IRC meeting this morning but it looks like that didn't happen. Has this been moved to once a month or was this a special week? Thanks, Sarah

3 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

virt May 2017