virt

virt@lists.centos.org

2 participants
1613 discussions

Live Migration and LibVirt CPU Mode
by Oisin O'Malley 06 Jul '17

06 Jul '17

Hi All, First time mailing here, I hope someone can help. We’re running a OpenStack Newton environment on top of CentOS-7.3, LibVirt and Qemu-KVM-EV. We are encountered an issue live migrating a VM between 2 hosts with different CPUs and LibVirt throws the following error: libvirtError: unsupported configuration: guest and host CPU are not compatible: Host CPU does not provide required features: fma, x2apic, movbe, tsc-deadline, xsave, osxsave, avx, f16c, rdrand, fsgsbase, tsc_adjust, bmi1, hle, avx2, smep, bmi2, erms, invpcid, rtm, rdseed, adx, smap, xsaveopt, abm, 3dnowprefetch; try using 'Broadwell-noTSX' CPU model. LibVirt appears to be comparing the source and destination host CPUs, instead of guest VM and destination host CPUs. The VM is configured with a common set CPU features that are compatible with both (see below) and can run on both hosts without issue. The hosts have Westmere and Broadwell CPUs (See host CPU capabilities below). The VM can be booted on the Westmere host, successfully live migrated to the Broadwell host, but then throws the above error when we attempt to live migrating back to the Westmere host. Due to how our Westmere hosts were configured in OpenStack Nova, the VMs CPU is configured with "cpu mode='host-model'", which fail to migrate. BUT if the VMs CPU is configured with "cpu mode='custom' match='exact'" it can be successfully migrate both ways. It appears that when a VMs CPU is configured with "cpu mode='host-model'" the guests CPU is ignored and the host CPUs are compared instead. Which I believe is incorrect behaviour, is this a known issue and/or have any workarounds. The VMs will be configure to use "cpu mode='custom'" with a Westmere model on their next reboot, but rebooting all VMs prior to migration is something we really want to avoid. There has already been some discussion on this issue on the OpenStack mailing list: http://lists.openstack.org/pipermail/openstack/2017-July/thread.html#45139 The following package versions are being used; libvirt-daemon-kvm.x86_642.0.0-10.el7_3.4 qemu-kvm-ev.x86_6410:2.6.0-28.el7_3.3.1 kernel.x86_643.10.0-514.16.1.el7 The Qemu-KVM processes CPU parameters of the running VMs; -cpu Westmere,+vme,+ds,+acpi,+ss,+ht,+tm,+pbe,+pclmuldq,+dtes64,+monitor,+ds_cpl,+vmx,+smx,+est,+tm2,+xtpr,+pdcm,+pcid,+dca,+arat,+pdpe1gb,+rdtscp Guest CPU Configuration that fails to migrate; <cpu mode='host-model'> <model fallback='allow'>Westmere</model> <vendor>Intel</vendor> <topology sockets='1' cores='1' threads='1'/> <feature policy='require' name='vme'/> <feature policy='require' name='ds'/> <feature policy='require' name='acpi'/> <feature policy='require' name='ss'/> <feature policy='require' name='ht'/> <feature policy='require' name='tm'/> <feature policy='require' name='pbe'/> <feature policy='require' name='pclmuldq'/> <feature policy='require' name='dtes64'/> <feature policy='require' name='monitor'/> <feature policy='require' name='ds_cpl'/> <feature policy='require' name='vmx'/> <feature policy='require' name='smx'/> <feature policy='require' name='est'/> <feature policy='require' name='tm2'/> <feature policy='require' name='xtpr'/> <feature policy='require' name='pdcm'/> <feature policy='require' name='pcid'/> <feature policy='require' name='dca'/> <feature policy='require' name='arat'/> <feature policy='require' name='pdpe1gb'/> <feature policy='require' name='rdtscp'/> </cpu> Guest CPU Configuration that successfully migrates; <cpu mode='custom' match='exact'> <model fallback='allow'>Westmere</model> <topology sockets='1' cores='1' threads='1'/> </cpu> Westmere Hosts CPU capabilities; <cpu> <arch>x86_64</arch> <model>Westmere</model> <vendor>Intel</vendor> <topology sockets='1' cores='4' threads='2'/> <feature name='vme'/> <feature name='ds'/> <feature name='acpi'/> <feature name='ss'/> <feature name='ht'/> <feature name='tm'/> <feature name='pbe'/> <feature name='pclmuldq'/> <feature name='dtes64'/> <feature name='monitor'/> <feature name='ds_cpl'/> <feature name='vmx'/> <feature name='smx'/> <feature name='est'/> <feature name='tm2'/> <feature name='xtpr'/> <feature name='pdcm'/> <feature name='pcid'/> <feature name='dca'/> <feature name='arat'/> <feature name='pdpe1gb'/> <feature name='rdtscp'/> <feature name='invtsc'/> <pages unit='KiB' size='4'/> <pages unit='KiB' size='2048'/> <pages unit='KiB' size= Broadwell Host CPU Capabilities; <cpu> <arch>x86_64</arch> <model>Broadwell</model> <vendor>Intel</vendor> <topology sockets='1' cores='12' threads='2'/> <feature name='vme'/> <feature name='ds'/> <feature name='acpi'/> <feature name='ss'/> <feature name='ht'/> <feature name='tm'/> <feature name='pbe'/> <feature name='dtes64'/> <feature name='monitor'/> <feature name='ds_cpl'/> <feature name='vmx'/> <feature name='smx'/> <feature name='est'/> <feature name='tm2'/> <feature name='xtpr'/> <feature name='pdcm'/> <feature name='dca'/> <feature name='osxsave'/> <feature name='f16c'/> <feature name='rdrand'/> <feature name='arat'/> <feature name='tsc_adjust'/> <feature name='cmt'/> <feature name='xsaveopt'/> <feature name='mbm_total'/> <feature name='mbm_local'/> <feature name='pdpe1gb'/> <feature name='abm'/> <feature name='invtsc'/> <pages unit='KiB' size='4'/> <pages unit='KiB' size='2048'/> <pages unit='KiB' size='1048576'/> </cpu> Regards, Oisin Oisin O'Malley Systems Engineer Iocane Pty Ltd 763 South Road Black Forest SA 5035 Office:+61 (8) 8413 1010 Fax:+61 (8) 8231 2050 Email:oisin.omalley@iocane.com.au Web:www.iocane.com.au Better for business

3 2

Lightweight alternative to virt-manager
by C. L. Martinez 04 Jul '17

04 Jul '17

Hi all, Anyone knows any lightweight alternative to virt-manager that works with linux, Windows and macos? Searching I have found ovirt only but it is too heavy. Thanks

4 4

Xen 4.6.3-15 packages, including XSAs 216-219, 221-225 on their way through the build system
by George Dunlap 27 Jun '17

27 Jun '17

Xen 4.6.3-15 packages for CentOS 6 and CentOS 7 are on their way through the build system. They should show up in centos-virt-testing in a few hours, and in the main mirrors tomorrow morning (God willing). These contain several critical updates; users are encouraged to update as soon as possible. XSA 220 unfortunately had several dependencies on changes included in 4.6.4 and 4.6.5. This particular vulnerability is slightly lower priorty; so I have queued up an update to 4.6.5 which includes this patch. Once 4.6.3-15 is tagged for release, I'll start building 4.6.5 put it in centos-virt-testing for people to test. -George

5 4

Loss of DHCP destroys bridge
by Ken Bass 26 Jun '17

26 Jun '17

I am having trouble with recovery. Today due to electrical work I powered down my networks Router / DHCP server. My Centos 7 host machines lost their DHCP lease (they are actually static leases). Once I power my Router / DHCP server back up none of my virtual machine were accessible. It appears that when the DHCP lease was lost on the virt server the bridge of the KVM guest were all losts. A 'br show' had none of the guests anymore. So each guest was sending out DHCP requests as expected but since the guest was no longer bridged the packets went no-where. How do I handle proper recovery from this? The sequence on the host seemed to be: 07:00:00 I powered off the DHCP server and router for electrical work Jun 26 10:08:02 vm-server dhclient[973]: DHCPREQUEST on br0 to 192.168.2.1 port 67 (xid=0x7627186d) requests continue for quite some hours and then NetworkManager chimes in. Jun 26 14:55:23 vm-server NetworkManager[840]: <info> [1498503323.1518] dhcp4 (br0): state changed bound -> expire Jun 26 14:55:23 vm-server NetworkManager[840]: <info> [1498503323.1681] dhcp4 (br0): canceled DHCP transaction, DHCP client pid 973 Jun 26 14:55:23 vm-server NetworkManager[840]: <info> [1498503323.1681] dhcp4 (br0): state changed expire -> done Jun 26 14:55:23 vm-server NetworkManager[840]: <info> [1498503323.1684] device (br0): scheduling DHCPv4 restart in 120 seconds, 3 tries left (reason: lease expired) (looks like 3 tries of something) Jun 26 15:00:52 vm-server NetworkManager[840]: <warn> [1498503652.9531] dhcp4 (br0): request timed out Jun 26 15:00:52 vm-server NetworkManager[840]: <info> [1498503652.9532] dhcp4 (br0): state changed unknown -> timeout Jun 26 15:00:52 vm-server NetworkManager[840]: <info> [1498503652.9694] dhcp4 (br0): canceled DHCP transaction, DHCP client pid 15937 Jun 26 15:00:52 vm-server NetworkManager[840]: <info> [1498503652.9694] dhcp4 (br0): state changed timeout -> done Jun 26 15:00:52 vm-server NetworkManager[840]: <info> [1498503652.9697] device (br0): scheduling DHCPv4 restart in 120 seconds, 1 tries left (reason: lease expired) Jun 26 15:02:52 vm-server NetworkManager[840]: <info> [1498503772.9548] dhcp4 (br0): activation: beginning transaction (timeout in 45 seconds) Jun 26 15:02:52 vm-server NetworkManager[840]: <info> [1498503772.9566] dhcp4 (br0): dhclient started with pid 15994 Jun 26 15:02:52 vm-server dhclient[15994]: DHCPDISCOVER on br0 to 255.255.255.255 port 67 interval 4 (xid=0x54083ff1) Jun 26 15:03:37 vm-server NetworkManager[840]: <warn> [1498503817.9818] dhcp4 (br0): request timed out Jun 26 15:03:37 vm-server NetworkManager[840]: <info> [1498503817.9819] dhcp4 (br0): state changed unknown -> timeout Jun 26 15:03:37 vm-server NetworkManager[840]: <info> [1498503817.9981] dhcp4 (br0): canceled DHCP transaction, DHCP client pid 15994 Jun 26 15:03:37 vm-server NetworkManager[840]: <info> [1498503817.9981] dhcp4 (br0): state changed timeout -> done Jun 26 15:03:37 vm-server NetworkManager[840]: <info> [1498503817.9984] device (br0): state change: activated -> failed (reason 'ip-config-unavailable') [100 120 5] Jun 26 15:03:37 vm-server NetworkManager[840]: <info> [1498503817.9987] manager: NetworkManager state is now CONNECTED_LOCAL Jun 26 15:03:38 vm-server NetworkManager[840]: <warn> [1498503818.0457] device (br0): Activation: failed for connection 'br0' Jun 26 15:03:38 vm-server kernel: device enp3s0 left promiscuous mode Jun 26 15:03:38 vm-server kernel: br0: port 1(enp3s0) entered disabled state Jun 26 15:03:38 vm-server NetworkManager[840]: <info> [1498503818.0473] device (br0): detached bridge port enp3s0 Jun 26 15:03:38 vm-server kernel: device vnet0 left promiscuous mode Jun 26 15:03:38 vm-server kernel: br0: port 2(vnet0) entered disabled state Jun 26 15:03:38 vm-server NetworkManager[840]: <info> [1498503818.0483] device (br0): detached bridge port vnet0 Jun 26 15:03:38 vm-server kernel: device vnet2 left promiscuous mode Jun 26 15:03:38 vm-server kernel: br0: port 3(vnet2) entered disabled state Jun 26 15:03:38 vm-server NetworkManager[840]: <info> [1498503818.0493] device (br0): detached bridge port vnet2 Jun 26 15:03:38 vm-server kernel: device vnet3 left promiscuous mode When I powered back on at: Jun 26 16:45:29 vm-server dhclient[26539]: DHCPOFFER from 192.168.2.1 Jun 26 16:45:29 vm-server dhclient[26539]: DHCPACK from 192.168.2.1 (xid=0x4c7b48be) None of the bridges that NetworkManager decided to detach were restored. Is this the case of being bitten by NetworkManager once again? Not sure why I am running it other than it is the default and I don't remember if it is responsible for setting up the bridges.

1 0

qemu-kvm-ev-2.6.0-28.el7_3.10.1 now available
by Sandro Bonazzola 23 Jun '17

23 Jun '17

Hi, qemu-kvm-ev-2.6.0-28.el7.10.1 <https://cbs.centos.org/koji/buildinfo?buildID=17495> has been tagged for release and will soon be available on CentOS mirrors. This release addresses a security issue (CVE-2017-7718) which has a security impact rated important. See https://www.redhat.com/archives/rhsa-announce/2017-June/msg00014.html for more details on this update. Here's the Changelog: * Fri Jun 23 2017 Sandro Bonazzola <sbonazzo(a)redhat.com> - ev-2.6.0-28.el7_3.10.1 - Removing RH branding from package name * Mon May 22 2017 Miroslav Rezanina <mrezanin(a)redhat.com> - rhev-2.6.0-28.el7_3.10 - kvm-virtio-rng-stop-virtqueue-while-the-CPU-is-stopped.patch [bz#1450375] - Resolves: bz#1450375 (Migration failed with postcopy enabled from rhel7.3.z host to rhel7.4 host "error while loading state for instance 0x0 of device 'pci) -- 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>

2 3

xen4centos kernel version / debuginfo
by Sarah Newman 13 Jun '17

13 Jun '17

Is there any problem moving to 4.9.31? This contains upstream commits f2e767bb5d6ee0d9 for mpt3sas and 69861e0a52f87333 for dom0 memory mappings. I am also trying to build a debuginfo package but it's not correct. Specifically I'm able to get vmlinux but the .debug files for modules are stripped, which isn't right. Does anyone know how to fix this? I'm also not sure how you're supposed to build the kernel-firmware package with the current spec file definition. --Sarah

3 3

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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

virt