virt

virt@lists.centos.org

1610 discussions

Copying CentOS AMIs for EBS encryption
by Andrew Hodgson 08 Aug '17

08 Aug '17

Hi, I am trying to copy the latest CentOS image to my own AWS account so that I can enable EBS volume encryption. It currently looks like the option when sharing the image is not enabled to allow direct copying of the snapshots, and I am wondering if this could be looked at? I can start an instance with this AMI, then create a new snapshot for the purpose of enabling EBS volume encryption, but I want to keep the image as clean as possible, and am worried if I run the image then some scripts will get ran that will customise the image with keys etc. If there is a better way to do this then happy to discuss. Thanks, Andrew.

2 2

Unsubscribe
by David Arnold 05 Aug '17

05 Aug '17

> On Aug 5, 2017, at 6:00 AM, centos-virt-request(a)centos.org wrote: > > Send CentOS-virt mailing list submissions to > centos-virt(a)centos.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.centos.org/mailman/listinfo/centos-virt > or, via email, send a message with subject or body 'help' to > centos-virt-request(a)centos.org > > You can reach the person managing the list at > centos-virt-owner(a)centos.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of CentOS-virt digest..." > > > Today's Topics: > > 1. Re: Copying CentOS AMIs for EBS encryption (Andrew Hodgson) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 4 Aug 2017 21:11:24 +0000 > From: Andrew Hodgson <andrew(a)hodgsonfamily.org> > To: "centos-virt(a)lists.centos.org" <centos-virt(a)lists.centos.org> > Subject: Re: [CentOS-virt] Copying CentOS AMIs for EBS encryption > Message-ID: > <AM5PR0802MB25463D4E82490F0F84C6E8C9C5B60(a)AM5PR0802MB2546.eurprd08.prod.outlook.com> > > Content-Type: text/plain; charset="us-ascii" > > I, > > Just wondering if anyone was able to look at this option with the current images or could share some tips on copying the image to another AWS account so we can use EBS encryption on the volume without tainting the image too much? > > Thanks. > Andrew. > > -----Original Message----- > From: Andrew Hodgson > Sent: 27 July 2017 15:09 > To: centos-virt(a)lists.centos.org > Subject: Copying CentOS AMIs for EBS encryption > > Hi, > > I am trying to copy the latest CentOS image to my own AWS account so that I can enable EBS volume encryption. It currently looks like the option when sharing the image is not enabled to allow direct copying of the snapshots, and I am wondering if this could be looked at? I can start an instance with this AMI, then create a new snapshot for the purpose of enabling EBS volume encryption, but I want to keep the image as clean as possible, and am worried if I run the image then some scripts will get ran that will customise the image with keys etc. > > If there is a better way to do this then happy to discuss. > > Thanks, > Andrew. > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > CentOS-virt mailing list > CentOS-virt(a)centos.org > https://lists.centos.org/mailman/listinfo/centos-virt > > > ------------------------------ > > End of CentOS-virt Digest, Vol 120, Issue 1 > *******************************************

1 0

AWS EC2 - CentOS 6 + 7 AMIs for new g3.* instance types?
by Stephan Koledin 27 Jul '17

27 Jul '17

Hello- Does anyone one this list maintain the official CentOS 6 + 7 AMIs in AWS? If so, could you please enable those images for use with the new g3.* instance types? If this list is the wrong place for this request, please point me in the right direction. Thanks! -Stephan

4 4

kernel-4.9.37-29.el7 (and el6)
by Johnny Hughes 24 Jul '17

24 Jul '17

Are the testing kernels (kernel-4.9.37-29.el7 and kernel-4.9.37-29.el6, with the one config file change) working for everyone: (turn off: CONFIG_IO_STRICT_DEVMEM) If we don't hear any negative comments by Wednesday July 19th, 2017 then we are going to push those to updates as they solve iscsi issues with some hardware and don't seem to impact anything else based on limited testing. BTW .. to test, edit the xen repo config file in /etc/yum.repos.d/ and turn on the testing repository .. or yum --enablerepo=centos-virt-xen-testing upgrade kernel* Thanks, Johnny Hughes

6 18

OVS+DPDK Problem
by Daniel Petrescu 20 Jul '17

20 Jul '17

Hi All, First time mailing here. I have installed on a CentOS 7.0 KVM (with DPDK and OVS) one Deep Packet Inspection VM. I have one channel and some virtual traffic generator. The traffic is lost between dpdk vhostuser and the DPI VM. The setup is attached. Any suggestions or ideas? Regarding the OVS+DPDK configuration, the following configuration is already made: - SELINUX is disabled - QEMU 2.9.0 was downloaded from sources - All Linux packages were updated for QEMU 2.9.0 - DPDK source was downloaded - Paths were set - epel repo was installed - DPDK 16.11 was installed - OVS 2.7.0 was installed with DPDK option - Hugepages VM is set - NICs are configured for DPDK - Permissions are set for DPDK Regarding the OVS+DPDK startup steps, the following configuration is in place: B. OVS+DPDK startup and configuration 1. Set and verify the memory hugepages mount -t hugetlbfs nodev /mnt/huge echo 64 > /sys/devices/system/node/node0/hugepages/hugepages- 1048576kB/nr_hugepages 2. Setting the driver permissions modprobe vfio-pci /usr/bin/chmod a+x /dev/vfio /usr/bin/chmod 0666 /dev/vfio/* 3. Configure the PATHS to DPDK and OVS database cd dpdk-stable-16.11.1/ export DPDK_DIR=$PWD export PATH=$PATH:/usr/local/share/openvswitch/scripts export DB_SOCK=/usr/local/var/run/openvswitch/db.sock 4. Re-initializing OVS rm /usr/local/etc/openvswitch/conf.db mkdir -p /usr/local/etc/openvswitch mkdir -p /usr/local/var/run/openvswitch ovsdb-tool create /usr/local/etc/openvswitch/conf.db /usr/local/share/openvswitch/vswitch.ovsschema 5. Starting OVS + DPDK ovsdb-server --remote=punix:/usr/local/var/run/openvswitch/db.sock --remote=db:Open_vSwitch,Open_vSwitch,manager_options --pidfile --detach ovs-vsctl --no-wait set Open_vSwitch . other_config:dpdk-init=true ovs-vsctl --no-wait set Open_vSwitch . other_config:dpdk-socket-mem=" 1024,1024" ovs-ctl --no-ovsdb-server --db-sock="$DB_SOCK" start 6. Cheking driver mapping for NICs driverctl -v list-devices | grep -i net $DPDK_DIR/tools/dpdk-devbind.py --status 7. Adding OVS+DPDK bridge and ports ovs-vsctl add-br ch1int_dpdk -- set bridge ch1int_dpdk datapath_type=netdev ovs-vsctl add-br ch1ext_dpdk -- set bridge ch1ext_dpdk datapath_type=netdev ovs-vsctl add-port ch1int_dpdk nic810 -- set Interface nic810 type=dpdk options:dpdk-devargs=0000:81:00.0 ovs-vsctl add-port ch1ext_dpdk nic811 -- set Interface nic811 type=dpdk options:dpdk-devargs=0000:81:00.1 8. Adding OVS (no DPDK) bridge and ports ovs-vsctl add-br br0 ovs-vsctl add-port br0 myportnameone 9. Adding VM ports to OVS (or OVS+DPDK) bridge #<interface type='bridge'> # <mac address='52:54:00:cb:57:af'/> # <source bridge='br0'/> # <virtualport type='openvswitch'/> # ... #</interface> 10. Adding dpdkvhostuser to the ovs switch - these are used for the socket created between the VM and the OVS bridge ovs-vsctl add-port ch1int_dpdk ch1int_dvhu -- set Interface ch1int_dvhu type=dpdkvhostuser ovs-vsctl add-port ch1ext_dpdk ch1ext_dvhu -- set Interface ch1ext_dvhu type=dpdkvhostuser 11. DPI deployment virt-install --connect qemu:///system --name=DPI --memory=16384 --vcpus=16 --os-type=linux --os-variant=virtio26 --disk path=/path/image.qcow2,format=qcow2,bus=virtio,cache=none --network bridge=admin,model=e1000 --nographics --noautoconsole --import 12. Adding vhostuser ports to guest VM - for this the XML file for the virtual machine found at etc/libvirt/qemu/<VM_name>.xml was edited <interface type='vhostuser'> <mac address='52:54:00:2f:e8:de'/> <source type='unix' path='/usr/local/var/run/openvswitch/ch1int_dvhu' mode='client'/> <model type='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/> </interface> <interface type='vhostuser'> <mac address='52:54:00:b9:40:d0'/> <source type='unix' path='/usr/local/var/run/openvswitch/ch1ext_dvhu' mode='client'/> <model type='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/> </interface> Thanks, Daniel

1 0

4.9.34-29 EL6 and EL7 kernels
by Johnny Hughes 13 Jul '17

13 Jul '17

OK Guys and Gals, We have just kicked off a build of the 4.9.34-29 xen kernel on the Community Build Service for both EL6 and EL7. This kernel has some important things in it. 1. It has a patch for the stack guard issue (CVE-2017-1000364). Also the patch for Xen Security fix XSA-216. See these upstream changelogs for ALL kernel commits from 4.9.31 to 4.9.34: https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.9.32 https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.9.33 https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.9.34 2. It has a fix for the xen-netback rate limit queues (http://www.spinics.net/lists/netdev/msg441578.html) (Thanks very much to Kevin Stange and Jean-Louis Dupond for finding a fix for this issue) 3. It now contains debuginfo files (thanks to Sarah Newman for this amazing addition!). ===================== The kernels are currently building, it will likely take 4 to 6 hours for them to make their way to the applicable testing repos: CentOS-7: https://buildlogs.centos.org/centos/7/virt/x86_64/xen-46/ or CentOS-6: https://buildlogs.centos.org/centos/6/virt/x86_64/xen-44/ https://buildlogs.centos.org/centos/6/virt/x86_64/xen-46/ ===================== If you actually need the debuginfo files, they will be here (also in 4 or so hours): CentOS-7: http://cbs.centos.org/repos/virt7-xen-common-testing/x86_64/debug/ CentOS-6: http://cbs.centos.org/repos/virt6-xen-common-testing/x86_64/debug/ ===================== Let's do some real testing of these and see if we can solve the issues people are having .. this should already solve server and the debuginfo files should help solve others. I think Kevin and Jean-Louis also know how to solve the Windows BSOD when run on a Xen 4.9.x dom0 server .. they can comment here. Hopefully whoever maintains the newer Windows drivers will fix the ACPI / APIC issues and no work around will be necessary soon(ish). I also want to personally (and publicly) thank Kevin, Jean-Louis, and Sarah for the substantial work and the community collaboration. This is EXACTLY what we need for the Virt SIG .. people solving problems and doing github pull requests so we can, together as a group, get these projects working much better. If someone else wants to help us with the Kernel .. or Xen .. here are our github branches: https://github.com/CentOS-virt7/xen-kernel https://github.com/CentOS-virt7/xen Fork them .. work on them .. talk to us on #centos-virt in freenode or on this mailing list .. then once we are all happy, you can submit a pull request and we'll get your issues fixed. Thanks, Johnny Hughes

2 2

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

virt