virt March 2017

virt@lists.centos.org

25 participants
16 discussions

unable to execute QEMU command 'migrate': this feature or command is not currently supported
by Valentin Guggiana 11 Apr '17

11 Apr '17

Hi all I'm trying to do a live migration with non-shared storage on CentOS 7. It was working well doing it from CentOS 6 to CentOS 7 but not between to CentOS 7 machines. I read that this feature was removed in RHEL/CentOS 7 but should be available in the CentOS-QEMU-EV repository. But I still get the error using qemu-kvm-ev: error: internal error: unable to execute QEMU command 'migrate': this feature or command is not currently supported My installed libvirt and qemu packets are: libvirt-2.0.0-10.el7_3.5.x86_64 libvirt-client-2.0.0-10.el7_3.5.x86_64 libvirt-daemon-2.0.0-10.el7_3.5.x86_64 libvirt-daemon-config-network-2.0.0-10.el7_3.5.x86_64 libvirt-daemon-config-nwfilter-2.0.0-10.el7_3.5.x86_64 libvirt-daemon-driver-interface-2.0.0-10.el7_3.5.x86_64 libvirt-daemon-driver-lxc-2.0.0-10.el7_3.5.x86_64 libvirt-daemon-driver-network-2.0.0-10.el7_3.5.x86_64 libvirt-daemon-driver-nodedev-2.0.0-10.el7_3.5.x86_64 libvirt-daemon-driver-nwfilter-2.0.0-10.el7_3.5.x86_64 libvirt-daemon-driver-qemu-2.0.0-10.el7_3.5.x86_64 libvirt-daemon-driver-secret-2.0.0-10.el7_3.5.x86_64 libvirt-daemon-driver-storage-2.0.0-10.el7_3.5.x86_64 libvirt-glib-0.2.3-1.el7.x86_64 libvirt-python-2.0.0-2.el7.x86_64 qemu-img-ev-2.6.0-28.el7_3.6.1.x86_64 qemu-kvm-common-ev-2.6.0-28.el7_3.6.1.x86_64 qemu-kvm-ev-2.6.0-28.el7_3.6.1.x86_64 qemu-kvm-tools-ev-2.6.0-28.el7_3.6.1.x86_64 My command is: virsh migrate --live --copy-storage-all --persistent --undefinesource --tunnelled --p2p --verbose --xml server.xml server qemu+ssh://xxx@a.b.c.d/system Any help would be greatly appreciated. Thanks, Valentin

3 5

Xen C6 kernel 4.9.13 and testing 4.9.15 only reboots.
by PJ Welsh 07 Apr '17

07 Apr '17

Updating my CentOS 6.8 Xen server with new 4.9.13 kernel yields a kernel boot message of a few like "APIC ID MISMATCH" and the system reboots immediately without any other bits of info. This is on a Dell R710 with 64GB RAM and 2x 6-core Intel CPU's. As an additional test, I installed and attempted to run the current "testing" kernel of 4.9.16 with the exact same results. Anyone have an idea? The 3.18.x series runs without issue of course. Thanks PJ

8 23

Network isolation for KVM guests
by C. L. Martinez 04 Apr '17

04 Apr '17

Hi all, What options exists under CentOS hosts to work with isolated networks?. For example, on BSD systems it is really trivial. In FreeBSD you can use setfib tools and on OpenBSD it is possible to use rdomain options. In 30 secs it is possible to work with isolated networks and assign process, ip address and routes (hidden from the main route table and ip addresses), etc. But I can't find a similar solution for CentOS environments. I have found two similar options: a/ Network namespaces (but doesn't provides a real network isolation) b/ VRF (but it is supported only for kernels 4.8 and up) Any ideas? Thanks. -- Greetings, C. L. Martinez

6 12

Xen 4.6.3-9 release
by Brandon Shoemaker 03 Apr '17

03 Apr '17

Hi list, Xen 4.6.3-9 will be general release soon?

2 2

2.6.0-28.el7_3.6.1 e1000 problem
by Dmitry Melekhov 31 Mar '17

31 Mar '17

Hello! We tried to move Windows 2003 VM with e1000 driver from Centos 7 which runs qemu-kvm-0.12.1.2-2.491.el6_8.7.x86_64 to Centos 7 with qemu-kvm-ev-2.6.0-28.el7_3.6.1.x86_64 and we got problems- tcp sessions, namely smb connections, randomly drops. We didn't test previous qemu-rhev with this VM, so we don't know how it works in them. Could you tell me is this known problem? Any workaround except switching to virtio? Thank you!

2 2

NIC Stability Problems Under Xen 4.4 / CentOS 6 / Linux 3.18
by Kevin Stange 29 Mar '17

29 Mar '17

I have three different types of CentOS 6 Xen 4.4 based hypervisors (by hardware) that are experiencing stability issues which I haven't been able to track down. All three types seem to be having issues with NIC and/or PCIe. In most cases, the issues are unrecoverable and require a hard boot to resolve. All have Intel NICs. Often the systems will remain stable for days or weeks, then suddenly encounter one of these issues. I have yet to tie the error to any specific action on the systems and can't reproduce it reliably. - Supermicro X8DT3, Dual Xeon E5620, 2x 82575EB NICs, 2x 82576 NICs Kernel messages upon failure: pcieport 0000:00:03.0: AER: Multiple Corrected error received: id=0018 pcieport 0000:00:03.0: PCIe Bus Error: severity=Corrected, type=Transaction Layer, id=0018(Receiver ID) pcieport 0000:00:03.0: device [8086:340a] error status/mask=00002000/00001001 pcieport 0000:00:03.0: [13] Advisory Non-Fatal pcieport 0000:00:03.0: Error of this Agent(0018) is reported first igb 0000:04:00.0: PCIe Bus Error: severity=Corrected, type=Physical Layer, id=0400(Receiver ID) igb 0000:04:00.0: device [8086:10a7] error status/mask=00002001/00002000 igb 0000:04:00.0: [ 0] Receiver Error (First) igb 0000:04:00.1: PCIe Bus Error: severity=Corrected, type=Physical Layer, id=0401(Receiver ID) igb 0000:04:00.1: device [8086:10a7] error status/mask=00002001/00002000 igb 0000:04:00.1: [ 0] Receiver Error (First) This spams to the console continuously until hard booting. - Supermicro X9DRD-iF/LF, Dual Xeon E5-2630, 2x I350, 2x 82575EB igb 0000:82:00.0: Detected Tx Unit Hang Tx Queue <1> TDH <43> TDT <50> next_to_use <50> next_to_clean <43> buffer_info[next_to_clean] time_stamp <12e6bc0b6> next_to_watch <ffff880006aa7440> jiffies <12e6bc8dc> desc.status <1c8210> This spams to the console continuously until hard booting. - Supermicro X9DRT, Dual Xeon E5-2650, 2x I350, 2x 82571EB e1000e 0000:04:00.0 eth2: Detected Hardware Unit Hang: TDH <ff> TDT <33> next_to_use <33> next_to_clean <fd> buffer_info[next_to_clean]: time_stamp <138230862> next_to_watch <ff> jiffies <138231ac0> next_to_watch.status <0> MAC Status <80383> PHY Status <792d> PHY 1000BASE-T Status <3c00> PHY Extended Status <3000> PCI Status <10> This type of system, the NIC automatically recovers and I don't need to reboot. So far I tried using pcie_aspm=off to see that would help, but it appears that the 3.18 kernel turns off ASPM by default on these due to probing the BIOS. Stability issues were not resolved by the changes. On the latter system type I also turned off all offloading setting. It appears the stability increased slightly but it didn't fully resolve the problem. I haven't adjusted offload settings on the first two server types yet. I suspect this problem is related to the 3.18 kernel used by the virt SIG, as we had these running Xen on CentOS 5's kernel with no issues for years, and systems of these types used elsewhere in our facility are stable under CentOS 6's standard kernel. This affects more than one server of each type, so I don't believe it is a hardware failure, or else it's a hardware design flaw. Has anyone experienced similar issues with this configuration, and if so, does anyone have tips on how to resolve the issues? -- 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

8 35

Upgrade to Xen 4.7
by Francis The Metman 28 Mar '17

28 Mar '17

Dear All I am running CentOS 7 with Xen 4.6 I see 4.7 is out now, and want to upgrade to see if the USB Passthrough will work. I have not been able to get it to work in 4.6 What is the best way to upgrade. I am using the centos-release-xen at the moment. Regards Francis

2 2

grub-bootxen.sh
by Alvin Starr 25 Mar '17

25 Mar '17

This is not abit issue just a minor annoyance. I use Foreman to provision my systems and to keep control I remove all the default *.repo files andkeep away from installing more *.repo files so I can control the content via the foreman(katello) provided redhat.repo. I would argue that the *-release-*.rpm should not contain any setup code but just the stuff in /etc/yum.repos.d. -- Alvin Starr || voice: (905)513-7688 Netvel Inc. || Cell: (416)806-0133 alvin(a)netvel.net ||

3 4

xen 4.7 or 4.8
by Christoph 21 Mar '17

21 Mar '17

Hi are there somewhere pkgs with xen 4.7 or 4.8 for centos7? -- ---------- Greetz Christoph

3 2

USB card reader causing qemu-kvm SEGV's
by Philip Prindeville 18 Mar '17

18 Mar '17

Hi. I have a Supermicro 5018D-FN4T (Xeon D-1541 based SBC) that I use for virtualization. I’m running Centos 7.3 on it (updated), with the CentOS-QEMU-EV.repo repository as the source for virtualization packages. I run an Ubuntu 16.04-2 guest VM on it, which is ordinary enough. What’s perhaps less ordinary is that I’ve attached a Lexar Media, Inc. “Lexar Professional Workflow CR1 CFast 2.0 USB 3.0 Reader” (LRWCR1TBNA) as well as a WEme Superspeed Aluminum USB 3.0 Multi-in-1 Card Reader … for CF/SD/TF Micro SD. Here’s the relevant lsusb output: Bus 004 Device 004: ID 0bda:0309 Realtek Semiconductor Corp. Bus 004 Device 025: ID 05dc:ba04 Lexar Media, Inc. and both are hanging off of an Amazon Basics 4-port USB 3.0 hub: Bus 004 Device 002: ID 2109:8110 VIA Labs, Inc. Hub The Ubuntu VM I use for doing buildroot cross builds of an embedded Linux environment, which I then burn the image of onto a CFast card, having attached the Lexar card reader to the guest VM. Problem is that the card reader is extremely dodgy, and sometimes I guess a flurry of messages on the virtualization host complaining about the device: Mar 11 15:52:46 kvm1 kernel: usb 4-2.2: Disable of device-initiated U1 failed. Mar 11 15:52:46 kvm1 kernel: usb 4-2.2: Disable of device-initiated U2 failed. Mar 11 15:52:46 kvm1 kernel: usb 4-2.2: Set SEL for device-initiated U1 failed. Mar 11 15:52:46 kvm1 kernel: usb 4-2.2: Set SEL for device-initiated U2 failed. Mar 11 15:52:47 kvm1 kernel: usb 4-2.2: reset SuperSpeed USB device number 25 using xhci_hcd Mar 11 15:52:47 kvm1 kernel: scsi host13: uas Mar 11 15:52:47 kvm1 kernel: scsi 13:0:0:0: Direct-Access Lexar WorkflowCR1 0 PQ: 0 ANSI: 6 Mar 11 15:52:47 kvm1 kernel: sd 13:0:0:0: [sda] 30198988 512-byte logical blocks: (15.4 GB/14.3 GiB) Mar 11 15:52:47 kvm1 kernel: sd 13:0:0:0: Attached scsi generic sg0 type 0 Mar 11 15:52:47 kvm1 kernel: sd 13:0:0:0: [sda] Write Protect is off Mar 11 15:52:47 kvm1 kernel: sd 13:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA Mar 11 15:52:47 kvm1 kernel: sda: sda1 sda2 Mar 11 15:52:47 kvm1 kernel: sd 13:0:0:0: [sda] Attached SCSI removable disk Mar 11 15:52:48 kvm1 kernel: usb 4-2.2: usbfs: process 4354 (CPU 3/KVM) did not claim interface 0 before use Mar 11 15:52:48 kvm1 kernel: usb 4-2.2: usbfs: process 4354 (CPU 3/KVM) did not claim interface 0 before use Mar 11 15:53:21 kvm1 kernel: usb 4-2.2: usbfs: process 4355 (CPU 4/KVM) did not claim interface 0 before use Mar 11 15:53:21 kvm1 kernel: usb 4-2.2: reset SuperSpeed USB device number 25 using xhci_hcd Mar 11 15:53:21 kvm1 kernel: usb 4-2.2: reset SuperSpeed USB device number 25 using xhci_hcd but lately it just kills my VM when I’m writing to the device. So from annoying to a serious potential for losing work. I run “yum update” a couple of times a week but now I’m thinking that was a mistake, since this has gone from being ultra-reliable to being a hazard. Is there a workaround? Would I be better off plugging the USB 3.0 card-reader into a USB 2.0 hub and settling for slower throughput… but not crashing? Below, for instance, I was doing a “dd if=xyzzy of=/dev/sda bs=1M” where /dev/sda is the device assigned to the USB card storage device. Thanks, -Philip URL for ABRT report: https://da.gd/emJO

3 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

virt March 2017