virt

virt@lists.centos.org

1610 discussions

Xen 4.6.6-8 in virt-testing
by George Dunlap 13 Dec '17

13 Dec '17

Xen 4.6.6-8 has been tagged in virt-testing. It contains XSAs 248-251, as well as an additional fix to XSA 240. Please test it if you get a chance and report any bugs; I'll probably push it to mirrors tomorrow if I don't hear anything. Peace, -George

2 2

ANNOUNCE: Upstream libvirt{, -python} releases built for CentOS
by Jiri Denemark 12 Dec '17

12 Dec '17

Hi all, Apparently some folks use CentOS for developing and/or testing software on top of libvirt (e.g., oVirt), which may be a bit troublesome since the version of libvirt released with CentOS is usually quite old compared to upstream. Using the downstream releases of libvirt for developing new features can introduce several months of delay, which may not be acceptable. So to make the development easier for folks who want to stick with CentOS I started to built upstream libvirt releases for Virt-SIG. The builds are not just a result of "make rpm", they are proper rebased versions of the released CentOS builds. In other words, all required downstream changes are ported to the new libvirt release. Regular CentOS builds essentially use one of these rebased builds as a base. You can expect both libvirt and libvirt-python CentOS builds within a few days after they are released upstream, unless I'm on vacation or CBS is not cooperating. The official repository for these build is http://mirror.centos.org/centos-7/7/virt/x86_64/libvirt-latest/ If you want packages for other architectures (there's no virt directory in http://mirror.centos.org/altarch/7/) you can use https://buildlogs.centos.org/centos/7/virt/$basearch/libvirt-latest/ or specifically https://buildlogs.centos.org/centos/7/virt/ppc64le/libvirt-latest/ https://buildlogs.centos.org/centos/7/virt/aarch64/libvirt-latest/ https://buildlogs.centos.org/centos/7/virt/x86_64/libvirt-latest/ Happy hacking. Jirka

1 0

Re: [CentOS-virt] [ovirt-users] qemu-kvm-ev-2.9.0-16.el7_4.11.1 now available for testing
by Sandro Bonazzola 12 Dec '17

12 Dec '17

2017-12-11 18:11 GMT+01:00 Markus Stockhausen <stockhausen(a)collogia.de>: > Hi Sandro, > > I'm wondering if BZ1513362 (AIO stuck fixed in qemu-kvm-rhev-2.9.0-16.el7_ > 4.12) > will be worth to give the newer version a try. > Above version is not yet released, can't see it on ftp://ftp.redhat.com/pub/redhat/linux/enterprise/7Server/en/RHEV/SRPMS/ > > Best regards. > > Markus > > --------------------- > *Von:* users-bounces(a)ovirt.org [users-bounces(a)ovirt.org]" im Auftrag von > "Sandro Bonazzola [sbonazzo(a)redhat.com] > *Gesendet:* Montag, 11. Dezember 2017 17:43 > *An:* Discussion about the virtualization on CentOS; devel; users > *Betreff:* [ovirt-users] qemu-kvm-ev-2.9.0-16.el7_4.11.1 now available > for testing > > Hi, qemu-kvm-ev-2.9.0-16.el7_4.11.1 > <https://cbs.centos.org/koji/buildinfo?buildID=21003> is now available > for testing. > If no negative feedback will be reported, I'm going to push to release on > Thursday, December 14th. > > Here's the changelog: > > * Mon Dec 11 2017 Sandro Bonazzola <sbonazzo(a)redhat.com> - > ev-2.9.0-16.el7_4.11.1 - Removing RH branding from package name * Mon Nov > 13 2017 Miroslav Rezanina <mrezanin(a)redhat.com> - rhev-2.9.0-16.el7_4.11 > - kvm-exec-use-qemu_ram_ptr_length-to-access-guest-ram.patch [bz#1472185] > - kvm-multiboot-validate-multiboot-header-address-values.patch > [bz#1501123] - Resolves: bz#1472185 (CVE-2017-11334 qemu-kvm-rhev: Qemu: > exec: oob access during dma operation [rhel-7.4.z]) - Resolves: bz#1501123 > (CVE-2017-14167 qemu-kvm-rhev: Qemu: i386: multiboot OOB access while > loading kernel image [rhel-7.4.z]) * Mon Oct 23 2017 Miroslav Rezanina < > mrezanin(a)redhat.com> - rhev-2.9.0-16.el7_4.10 - > kvm-vga-stop-passing-pointers-to-vga_draw_line-functions.patch > [bz#1501300] - kvm-vga-drop-line_offset-variable.patch [bz#1501300] - > kvm-vga-handle-cirrus-vbe-mode-wraparounds.patch [bz#1501300] - > kvm-cirrus-fix-oob-access-in-mode4and5-write-functions.patch [bz#1501300] > - Resolves: bz#1501300 (CVE-2017-15289 qemu-kvm-rhev: Qemu: cirrus: OOB > access issue in mode4and5 write functions [rhel-7.4.z]) * Mon Oct 09 2017 > Miroslav Rezanina <mrezanin(a)redhat.com> - rhev-2.9.0-16.el7_4.9 - > kvm-nbd-client-Fix-regression-when-server-sends-garbage.patch > [bz#1495474] - kvm-fix-build-failure-in-nbd_read_reply_entry.patch > [bz#1495474] - kvm-nbd-client-avoid-spurious-qio_channel_yield-re-entry.patch > [bz#1495474] - kvm-nbd-client-avoid-read_reply_co-entry-if-send-failed.patch > [bz#1495474] - kvm-qemu-iotests-improve-nbd-fault-injector.py-startup-p.patch > [bz#1495474] - kvm-qemu-iotests-test-NBD-over-UNIX-domain-sockets-in-08.patch > [bz#1495474] - kvm-block-nbd-client-nbd_co_send_request-fix-return-code.patch > [bz#1495474] - Resolves: bz#1495474 (Fail to quit source qemu when do live > migration after mirroring guest to NBD server [rhel-7.4.z]) > > <https://cbs.centos.org/koji/buildinfo?buildID=21003>-- > > SANDRO BONAZZOLA > > ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D > > Red Hat EMEA <https://www.redhat.com/> > <https://red.ht/sig> > TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> > > -- SANDRO BONAZZOLA ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D Red Hat EMEA <https://www.redhat.com/> <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>

1 0

qemu-kvm-ev-2.9.0-16.el7_4.11.1 now available for testing
by Sandro Bonazzola 11 Dec '17

11 Dec '17

Hi, qemu-kvm-ev-2.9.0-16.el7_4.11.1 <https://cbs.centos.org/koji/buildinfo?buildID=21003> is now available for testing. If no negative feedback will be reported, I'm going to push to release on Thursday, December 14th. Here's the changelog: * Mon Dec 11 2017 Sandro Bonazzola <sbonazzo(a)redhat.com> - ev-2.9.0-16.el7_4.11.1 - Removing RH branding from package name * Mon Nov 13 2017 Miroslav Rezanina <mrezanin(a)redhat.com> - rhev-2.9.0-16.el7_4.11 - kvm-exec-use-qemu_ram_ptr_length-to-access-guest-ram.patch [bz#1472185] - kvm-multiboot-validate-multiboot-header-address-values.patch [bz#1501123] - Resolves: bz#1472185 (CVE-2017-11334 qemu-kvm-rhev: Qemu: exec: oob access during dma operation [rhel-7.4.z]) - Resolves: bz#1501123 (CVE-2017-14167 qemu-kvm-rhev: Qemu: i386: multiboot OOB access while loading kernel image [rhel-7.4.z]) * Mon Oct 23 2017 Miroslav Rezanina <mrezanin(a)redhat.com> - rhev-2.9.0-16.el7_4.10 - kvm-vga-stop-passing-pointers-to-vga_draw_line-functions.patch [bz#1501300] - kvm-vga-drop-line_offset-variable.patch [bz#1501300] - kvm-vga-handle-cirrus-vbe-mode-wraparounds.patch [bz#1501300] - kvm-cirrus-fix-oob-access-in-mode4and5-write-functions.patch [bz#1501300] - Resolves: bz#1501300 (CVE-2017-15289 qemu-kvm-rhev: Qemu: cirrus: OOB access issue in mode4and5 write functions [rhel-7.4.z]) * Mon Oct 09 2017 Miroslav Rezanina <mrezanin(a)redhat.com> - rhev-2.9.0-16.el7_4.9 - kvm-nbd-client-Fix-regression-when-server-sends-garbage.patch [bz#1495474] - kvm-fix-build-failure-in-nbd_read_reply_entry.patch [bz#1495474] - kvm-nbd-client-avoid-spurious-qio_channel_yield-re-entry.patch [bz#1495474] - kvm-nbd-client-avoid-read_reply_co-entry-if-send-failed.patch [bz#1495474] - kvm-qemu-iotests-improve-nbd-fault-injector.py-startup-p.patch [bz#1495474] - kvm-qemu-iotests-test-NBD-over-UNIX-domain-sockets-in-08.patch [bz#1495474] - kvm-block-nbd-client-nbd_co_send_request-fix-return-code.patch [bz#1495474] - Resolves: bz#1495474 (Fail to quit source qemu when do live migration after mirroring guest to NBD server [rhel-7.4.z]) <https://cbs.centos.org/koji/buildinfo?buildID=21003>-- SANDRO BONAZZOLA ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D Red Hat EMEA <https://www.redhat.com/> <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>

1 0

4.4.4-26 with XSA-226, 227, 230 in centos-virt-testing
by Kevin Stange 28 Nov '17

28 Nov '17

Xen 4.4.4 along with kernel 4.9.44 containing patches for XSAs (226 - 230) from August 15th are now available in centos-virt-testing. If possible, please test and provide feedback here so we can move these to release soon. XSA-228 did not affect Xen 4.4 XSA-229 only applies to the kernel XSA-235 disclosed today only affects ARM and isn't going to be added to these packages. Thanks. -- 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 kevin(a)steadfast.net | www.steadfast.net

3 4

Xen 4.6.6-7 packages in virt-testing
by George Dunlap 28 Nov '17

28 Nov '17

I've tagged the 4.6.6-7, which contain XSAs 246 and 247, in testing; they should show up in virt-testing soon. Please report any issues; I'll probably tag for release tomorrow (to show up Thursday). -George

1 0

Stability issues since moving to 4.6 - Kernel paging request bug + VM left in null state
by Nathan March 15 Nov '17

15 Nov '17

Since moving from 4.4 to 4.6, I've been seeing an increasing number of stability issues on our hypervisors. I'm not clear if there's a singular root cause here, or if I'm dealing with multiple bugs. One of the more common ones I've seen, is a VM on shutdown will remain in the null state and a kernel bug is thrown: xen001 log # xl list Name ID Mem VCPUs State Time(s) Domain-0 0 6144 24 r----- 6639.7 (null) 3 0 1 --pscd 36.3 [89920.839074] BUG: unable to handle kernel paging request at ffff88020ee9a000 [89920.839546] IP: [<ffffffff81430922>] __memcpy+0x12/0x20 [89920.839933] PGD 2008067 [89920.840022] PUD 17f43f067 [89920.840390] PMD 1e0976067 [89920.840469] PTE 0 [89920.840833] [89920.841123] Oops: 0000 [#1] SMP [89920.841417] Modules linked in: ebt_ip ebtable_filter ebtables arptable_filter arp_tables bridge xen_pciback xen_gntalloc nfsd auth_rpcgss nfsv3 nfs_acl nfs fscache lockd sunrpc grace 8021q mrp garp stp llc bonding xen_acpi_processor blktap xen_netback xen_blkback xen_gntdev xen_evtchn xenfs xen_privcmd dcdbas fjes pcspkr ipmi_devintf ipmi_si ipmi_msghandler joydev i2c_i801 i2c_smbus lpc_ich shpchp mei_me mei ioatdma ixgbe mdio igb dca ptp pps_core uas usb_storage wmi ttm [89920.847080] CPU: 4 PID: 1471 Comm: loop6 Not tainted 4.9.58-29.el6.x86_64 #1 [89920.847381] Hardware name: Dell Inc. PowerEdge C6220/03C9JJ, BIOS 2.7.1 03/04/2015 [89920.847893] task: ffff8801b75e0700 task.stack: ffffc900460e0000 [89920.848192] RIP: e030:[<ffffffff81430922>] [<ffffffff81430922>] __memcpy+0x12/0x20 [89920.848783] RSP: e02b:ffffc900460e3b20 EFLAGS: 00010246 [89920.849081] RAX: ffff88018916d000 RBX: ffff8801b75e0700 RCX: 0000000000000200 [89920.849384] RDX: 0000000000000000 RSI: ffff88020ee9a000 RDI: ffff88018916d000 [89920.849686] RBP: ffffc900460e3b38 R08: ffff88011da9fcf8 R09: 0000000000000002 [89920.849989] R10: ffff88019535bddc R11: ffffea0006245b5c R12: 0000000000001000 [89920.850294] R13: ffff88018916e000 R14: 0000000000001000 R15: ffffc900460e3b68 [89920.850605] FS: 00007fb865c30700(0000) GS:ffff880204b00000(0000) knlGS:0000000000000000 [89920.851118] CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033 [89920.851418] CR2: ffff88020ee9a000 CR3: 00000001ef03b000 CR4: 0000000000042660 [89920.851720] Stack: [89920.852009] ffffffff814375ca ffffc900460e3b38 ffffc900460e3d08 ffffc900460e3bb8 [89920.852821] ffffffff814381c5 ffffc900460e3b68 ffffc900460e3d08 0000000000001000 [89920.853633] ffffc900460e3d88 0000000000000000 0000000000001000 ffffea0000000000 [89920.854445] Call Trace: [89920.854741] [<ffffffff814375ca>] ? memcpy_from_page+0x3a/0x70 [89920.855043] [<ffffffff814381c5>] iov_iter_copy_from_user_atomic+0x265/0x290 [89920.855354] [<ffffffff811cf633>] generic_perform_write+0xf3/0x1d0 [89920.855673] [<ffffffff8101e39a>] ? xen_load_tls+0xaa/0x160 [89920.855992] [<ffffffffc025cf2b>] nfs_file_write+0xdb/0x200 [nfs] [89920.856297] [<ffffffff81269062>] vfs_iter_write+0xa2/0xf0 [89920.856599] [<ffffffff815fa365>] lo_write_bvec+0x65/0x100 [89920.856899] [<ffffffff815fc375>] do_req_filebacked+0x195/0x300 [89920.857202] [<ffffffff815fc53b>] loop_queue_work+0x5b/0x80 [89920.857505] [<ffffffff810c6898>] kthread_worker_fn+0x98/0x1b0 [89920.857808] [<ffffffff818d9dca>] ? schedule+0x3a/0xa0 [89920.858108] [<ffffffff818ddbb6>] ? _raw_spin_unlock_irqrestore+0x16/0x20 [89920.858411] [<ffffffff810c6800>] ? kthread_probe_data+0x40/0x40 [89920.858713] [<ffffffff810c63f5>] kthread+0xe5/0x100 [89920.859014] [<ffffffff810c6310>] ? __kthread_init_worker+0x40/0x40 [89920.859317] [<ffffffff818de2d5>] ret_from_fork+0x25/0x30 [89920.859615] Code: 81 f3 00 00 00 00 e9 1e ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 66 90 66 90 48 89 f8 48 89 d1 48 c1 e9 03 83 e2 07 <f3> 48 a5 89 d1 f3 a4 c3 66 0f 1f 44 00 00 48 89 f8 48 89 d1 f3 [89920.864410] RIP [<ffffffff81430922>] __memcpy+0x12/0x20 [89920.864749] RSP <ffffc900460e3b20> [89920.865021] CR2: ffff88020ee9a000 [89920.865294] ---[ end trace b77d2ce5646284d1 ]--- Wondering if anyone has advice on how to troubleshoot the above, or might have some insight into that the issue could be? This hypervisor was only up for a day, had almost no VMs running on it since boot, I booted a single windows test VM which BSOD'ed and then this happened. This is on xen 4.6.6-4.el6 with 4.9.58-29.el6.x86_64. I see these issues across a wide number of systems with from both Dell and Supermicro, although we run the same Intel x540 10gb nic's in each system with the same netapp nfs backend storage. Cheers, Nathan

3 3

Live migration haswell, broadwell
by T.Weyergraf 14 Nov '17

14 Nov '17

Hi I wonder, if live migration (back and forth) is possible on mixed Haswell (Xeon V3) and Broadwell (Xeon V4) installations. The only notable difference between the two is apparently a working TSX implementation on V4, which got disabled on V3 due to bugs. The rest (VMCS-shadowing, posted interrupts) should not apply to our environment, as we do not run nested-vmx nor device-passthrough on our Xen servers. Now, I found no sane way to disable TSX on a given system but I cannot rule out, that some (Linux-)software, such as Postgres will use them eventually. Also, I have a hard time trying to assess, if TSX can be disabled on V4 to enable seamless migration. Any hint would be greately appreciated.

2 1

Crash in network stack under Xen
by Sarah Newman 13 Nov '17

13 Nov '17

Hi, We had a potentially network related crash on a dom0 with Linux 4.9.39 / Xen 4.8 and as of today I can't find any fixes in stable/linux-4.9.y, xen/staging-4.8, or CPU microcode updates that look like a smoking gun. I can't rule out that it's Xen related. The backtraces are: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 0 at net/ipv4/af_inet.c:1473 inet_gro_complete+0xbb/0xd0 Call Trace: <IRQ> dump_stack+0x63/0x8e __warn+0xd1/0xf0 warn_slowpath_null+0x1d/0x20 inet_gro_complete+0xbb/0xd0 napi_gro_complete+0x73/0xa0 napi_gro_flush+0x5f/0x80 napi_complete_done+0x6a/0xb0 igb_poll+0x38d/0x720 [igb] ? igb_msix_ring+0x2e/0x40 [igb] ? __handle_irq_event_percpu+0x4b/0x1a0 net_rx_action+0x158/0x360 __do_softirq+0xd1/0x283 irq_exit+0xe9/0x100 xen_evtchn_do_upcall+0x35/0x50 xen_do_hypervisor_callback+0x1e/0x40 <EOI> ? xen_hypercall_sched_op+0xa/0x20 ? xen_hypercall_sched_op+0xa/0x20 ? xen_safe_halt+0x10/0x20 ? default_idle+0x1e/0xd0 ? arch_cpu_idle+0xf/0x20 ? default_idle_call+0x2c/0x40 ? cpu_startup_entry+0x1ac/0x240 ? rest_init+0x77/0x80 ? start_kernel+0x4a7/0x4b4 ? set_init_arg+0x55/0x55 ? x86_64_start_reservations+0x24/0x26 ? xen_start_kernel+0x555/0x561 general protection fault: 0000 [#1] SMP Call Trace: <IRQ> ? napi_gro_complete+0x5e/0xa0 skb_release_all+0x24/0x30 kfree_skb+0x32/0x90 napi_gro_complete+0x5e/0xa0 napi_gro_flush+0x5f/0x80 napi_complete_done+0x6a/0xb0 igb_poll+0x38d/0x720 [igb] ? igb_msix_ring+0x2e/0x40 [igb] ? __handle_irq_event_percpu+0x4b/0x1a0 net_rx_action+0x158/0x360 __do_softirq+0xd1/0x283 irq_exit+0xe9/0x100 xen_evtchn_do_upcall+0x35/0x50 xen_do_hypervisor_callback+0x1e/0x40 <EOI> ? xen_hypercall_sched_op+0xa/0x20 ? xen_hypercall_sched_op+0xa/0x20 ? xen_safe_halt+0x10/0x20 ? default_idle+0x1e/0xd0 ? arch_cpu_idle+0xf/0x20 ? default_idle_call+0x2c/0x40 ? cpu_startup_entry+0x1ac/0x240 ? rest_init+0x77/0x80 ? start_kernel+0x4a7/0x4b4 ? set_init_arg+0x55/0x55 ? x86_64_start_reservations+0x24/0x26 ? xen_start_kernel+0x555/0x561 RIP skb_release_data+0x73/0xf0 Kernel panic - not syncing: Fatal exception in interrupt Kernel Offset: disabled (XEN) Hardware Dom0 crashed: rebooting machine in 5 seconds. If anyone has had a similar backtrace or knows of a potential fix please respond. This server has ECC and there were no ECC or other errors in the BIOS event log, nor were there any indications of any problems in the serial console log leading up to the warning. This particular server had an uptime of about a month and a half, and so far we've had this error exactly once across all our servers since switching to 4.9.39 in August, so I don't think it's going to be easy to reproduce. --- It looks to me like in the first backtrace, this check from inet_gro_complete failed: ops = rcu_dereference(inet_offloads[proto]); Which I'm guessing means the packet didn't have a valid layer 4 protocol definition, or we don't have that protocol enabled. Then when attempting to handle that failure there was a GPF, I believe by accessing invalid data in shinfo->frag_list . "skb_release_data+0x73" is in __read_once_size, which I think is generated by "kfree_skb: if (likely(atomic_read(&skb->users) == 1))" . --Sarah

2 1

Non Marketplace AMI for 1708
by Andrew Jeffree 13 Nov '17

13 Nov '17

Hi, Currently, there are some images that are published outside of the AWS Market Place [0] for 1703 are there plans to have updated ones available for 1708? Kind Regards, Andrew [0] - https://wiki.centos.org/Cloud/AWS#head-78d1e3a4e6ba5c5a3847750d88266916ffe6…

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

virt