virt

virt@lists.centos.org

2 participants
1612 discussions

Reminder: CentOS Virt SIG teleconf tomorrow (27 Jan), 2pm GMT
by Lars Kurth 26 Jan '15

26 Jan '15

Hey all, Just a reminder that we'll be resuming our bi-weekly Virt SIG meeting The meeting is by teleconf tomorrow. If you don't have the details let me know and I will add you. Also, I can send you the details on IRC a few minutes before the call, if you ping me. Basic agenda: * Xen update * Docker update * oVirt update * Replace audio meetings in favour of IRC meetings, which seem to work better * Any other business Please let me know if you have any other topics you'd like to bring up. -Lars

1 0

kvm guest from zfs dataset
by aurfalien 22 Jan '15

22 Jan '15

Hi all, I thought I’d post this in case any one has issues similar to mine. First, my initial email to the list which I didn’t send; I’m trying to run a KVM based guest OS off of a mirrored ZFS dataset. It won’t run with errors "invalid argument..", but will run when on the root volume, or when that ZFS dataset has been removed in favor of an EXT4 volumes. Thanks in advance, PS I do see this thread which is not promising; http://www.redhat.com/archives/redhat-list/2014-July/msg00017.html Lastly, the solution; Set your cache policy on the KVM guest as write back. This allows it to run on a ZFS volume. My apology if this has been covered. I did spend some time on this so hopefully you can save time by setting the cache policy. - aurf "Janitorial Services"

3 2

Xen 4.4 + libvirt 1.2 rpms test report with xl/libxl on CentOS 6
by Pasi Kärkkäinen 20 Jan '15

20 Jan '15

Hello, As discussed on the last Virt SIG meeting I promised to do some libvirt + libxl testing using the latest Xen 4.4 rpms. Versions used: xen-libs-4.4.1-5.el6.x86_64 xen-licenses-4.4.1-5.el6.x86_64 xen-hypervisor-4.4.1-5.el6.x86_64 xen-4.4.1-5.el6.x86_64 xen-runtime-4.4.1-5.el6.x86_64 kernel-3.10.63-11.el6.centos.alt.x86_64 libvirt-daemon-driver-nwfilter-1.2.10-3.el6.x86_64 libvirt-daemon-driver-xen-1.2.10-3.el6.x86_64 libvirt-daemon-driver-lxc-1.2.10-3.el6.x86_64 libvirt-daemon-1.2.10-3.el6.x86_64 libvirt-daemon-config-nwfilter-1.2.10-3.el6.x86_64 libvirt-daemon-driver-libxl-1.2.10-3.el6.x86_64 libvirt-daemon-driver-secret-1.2.10-3.el6.x86_64 libvirt-python-1.2.10-2.el6.x86_64 libvirt-daemon-driver-network-1.2.10-3.el6.x86_64 libvirt-daemon-config-network-1.2.10-3.el6.x86_64 libvirt-1.2.10-3.el6.x86_64 libvirt-client-1.2.10-3.el6.x86_64 libvirt-daemon-driver-interface-1.2.10-3.el6.x86_64 libvirt-daemon-driver-nodedev-1.2.10-3.el6.x86_64 libvirt-daemon-driver-qemu-1.2.10-3.el6.x86_64 libvirt-daemon-driver-storage-1.2.10-3.el6.x86_64 python-virtinst-0.600.0-25.el6.centos.alt.noarch First I verified the "baseline" setup using xm/xend and libvirt: - Install new PV domUs using virt-install, using LVM volumes. - Install new PV domUs using virt-install, using file images (tap2). - Install new PV domUs using virt-manager, using LVM volumes. - Install new PV domUs using virt-manager, using file images (tap2). And all that worked OK with xend, as we already know. "tap2" backend was now automatically chosen for file images etc, all good. Next I tried the same with xl/libxl. So I disabled xend with "chkconfig xend off", rebooted the server, and after the reboot verified xend is not running anymore. And then I did the same PV domU installation tests as above.. and to my surprise it all worked out-of-the-box ! libvirt 1.2.10 seems to be happy with libxl aswell! Both virt-install and virt-manager worked OK for me for installing new guests, and also for the basic lifecycle operations. One difference compared to our earlier libvirt 0.x rpms is this: # virsh version Compiled against library: libvirt 1.2.10 Using library: libvirt 1.2.10 Using API: Xen 1.2.10 Running hypervisor: Xen 4.4.0 Now I get the same output from "virsh version" for both xm/xend and xl/libxl.. Earlier it would say "Xen" or "xenlight" on the "Using API" line depending which backend it was using. I guess that has changed upstream, and both backends seem to work now anyway :) -- Pasi

3 3

SIG repo layout and conflicts between projects within a SIG
by George Dunlap 20 Jan '15

20 Jan '15

At the moment, we're essentially using yum repos as the "patch" mechanism to CentOS Base: SIGs populate a repo with packages they want to add / override, and all other packages default to Base. The current setup is that every sig has exactly one production repo per CentOS version. Also, we seem to be wanting to see SIGs not as individual projects, but to make the 'G' an actual "group": so, for instance, the Virt SIG has both Xen and Docker, and we've recently approved oVirt. But there's a bit of a conflict here: what if one project in the SIG wants to use the package from Base, and another project in the SIG wants to use a custom-built package? Or what if both projects want to customize their packages in different ways? In particular: the Docker project in the Virt SIG wants to supply updated versions of Docker; but at the moment uses the kernel package from Base. The Xen project, on the other hand, needs to supply a different kernel package that has dom0 support enabled. Up until this point, this hasn't been an issue because I've been doing Xen development in virt6-testing, and Lokesh has been doing Docker development in virt7-testing. But I'm hoping to get Xen for CentOS 7 out soon, and I was just about to upload the Xen kernel to the CBS, when it occurred to me that if I did so, then everyone using the virt7-testing repo for Docker would suddenly get my updated kernel as well. So it seems we have a couple of ways to approach it. 1. Keep it one repo per SIG, and make all projects in a SIG sort out shared dependencies. 2. Allow one repo per *project* within a SIG (e.g., virt6-xen, virt7-docker) 3. Have some alternate way of doing a "patch", instead of repos. In the case of xen / docker, I haven't talked with Lokesh about this at all; it may be that he's fine with sharing a kernel with Xen. But it does increase the workload: now Lokesh needs to maintain the Docker side of the kernel, whereas before they could just rely on our upstream to do a lot of that testing. Furthermore, it increases the complexity of development and testing: before when doing kernel work, I could just test Xen; now the kernel needs to be tested by both Xen and Docker. And finally, now users of both projects get a kernel update whenever either one does. Which, of course, is pretty much the same as any other distro; but as a whole, at the moment at least, we have a lot less resources than any other distro our size and popularity. On the whole I'm inclined to prefer #2. Thoughts? -George

3 2

Virt SIG Meeting minutes
by Lars Kurth 13 Jan '15

13 Jan '15

See * http://centos.org/minutes/2015/january/centos-devel.2015-01-13-14.06.html * http://centos.org/minutes/2015/january/centos-devel.2015-01-13-14.06.log.ht…

1 0

Reminder: CentOS Virt SIG meeting on IRC tomorrow (13 Jan), 2pm GMT
by George Dunlap 12 Jan '15

12 Jan '15

Hey all, Just a reminder that we'll be resuming our bi-weekly Virt SIG meeting on IRC tomorrow at 2pm. Basic agenda: * Xen update * Docker update * oVirt update * FOSDEM? * Any other business Please let me know if you have any other topics you'd like to bring up. -George

1 0

Libvirt save problem
by Cristian Del Carlo 12 Jan '15

12 Jan '15

Hi list, i use a centos 7 as virtual host with two guests with windows 2012 standard ( as storage i use RAW files). My problem is that sometime during the bakup my server reboot without leaving information in the log files ( /var/log/messages ). The backup does this steps: 1) Save the state of the virtual guest ( with the command "virsh save " ) 2) Make a snapshot of the filesystem ( with lvm2 ) 3) Make a backup of the snapshot I found that the problem is related with the save of the state, without saving the state i have no problem. Could you help me? Thanks. [root@kvm1 ~]# rpm -aq | grep libvirt libvirt-daemon-driver-interface-1.1.1-29.el7_0.3.x86_64 libvirt-daemon-config-nwfilter-1.1.1-29.el7_0.3.x86_64 libvirt-daemon-driver-storage-1.1.1-29.el7_0.3.x86_64 libvirt-daemon-driver-qemu-1.1.1-29.el7_0.3.x86_64 libvirt-daemon-1.1.1-29.el7_0.3.x86_64 libvirt-daemon-driver-secret-1.1.1-29.el7_0.3.x86_64 libvirt-daemon-driver-network-1.1.1-29.el7_0.3.x86_64 libvirt-client-1.1.1-29.el7_0.3.x86_64 libvirt-daemon-driver-nwfilter-1.1.1-29.el7_0.3.x86_64 libvirt-1.1.1-29.el7_0.3.x86_64 libvirt-daemon-driver-nodedev-1.1.1-29.el7_0.3.x86_64 libvirt-daemon-config-network-1.1.1-29.el7_0.3.x86_64 libvirt-daemon-driver-lxc-1.1.1-29.el7_0.3.x86_64 Kernel 3.10.0-123.8.1.el7.x86_64 #1 SMP. [root@kvm1 ~]# rpm -aq | grep qemu libvirt-daemon-driver-qemu-1.1.1-29.el7_0.3.x86_64 qemu-kvm-1.5.3-60.el7_0.7.0.1.x86_64 qemu-system-x86-2.0.0-1.el7.1.x86_64 ipxe-roms-qemu-20130517-5.gitc4bce43.el7.noarch qemu-img-1.5.3-60.el7_0.7.0.1.x86_64 qemu-common-2.0.0-1.el7.1.x86_64 qemu-kvm-common-1.5.3-60.el7_0.7.0.1.x86_64 [root@kvm1 ~]# rpm -aq | grep lvm2 lvm2-2.02.105-14.el7.x86_64 lvm2-libs-2.02.105-14.el7.x86_64 -- -------------------------------------------------------- Cristian Del Carlo Il testo e gli eventuali documenti trasmessi contengono informazioni riservate al destinatario indicato. La seguente e-mail è confidenziale e la sua riservatezza è tutelata legalmente dal Decreto Legislativo 196 del 30/06/2003 (Codice di tutela della privacy). La lettura, copia o altro uso non autorizzato o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere, immediatamente, alla sua distruzione. --------------------------------------------------------

1 0

CPU Hot Plug/Unplug with KVM on CentOS
by roy simkes 08 Jan '15

08 Jan '15

Hello, I'm trying to plug and unplug cpus with a host CentOS 7 on a guest machine with CentOS too. I have created the guest with virt-install command, modified my domxml to have maximum 4 vcpus and updated the current cpu to 2. After that I open the virsh console, and used command setvcpus to add/remove cpus. I was able to increase the vcpu count until 4 but can't increase it after 4 as it exceeds maximum vcpu count. However when I want to remove vcpus, again by using setvcpus command, I noticed that it's not possbile. I have looked around and found a changelog related to CentOS 6.5 where unplugging was supported. To check that, I have installed CentOS 6.5 on the host machine and tried again and noticed that it worked. I used the commands as this: virsh -c qemu:///system setvcpus myguest 3 setvcpus myguest 2 (Caused an error on CentOS 7 but not on 6.5) The excerpt from my domxml related to the cpus is like this: <vcpu placement='static' current="2">4</vcpu> I can again see those cpus being plugged and unplugged using the /proc/cpuinfo I have looked around a little bit but I was unable to find why this happened. Can you direct me to the right place to look or tell me if this is a bug or not? Or is it something related to the libvirt and not kvm/qemu? Thanks roy

1 0

Joining the SIG - oVirt project
by Sandro Bonazzola 08 Jan '15

08 Jan '15

Hi, I just joined the CentOS-virt call yesterday for the first time and it was a pleasure to meet you there. My name is Sandro Bonazzola[1] and I'm a member of the integration team and the release engineering manager for oVirt project[2]. oVirt is an open source alternative to VMware vSphere, and provides an excellent KVM management interface for multi-node virtualization. On each release we provide packages for Fedora and CentOS 6 and starting with the upcoming release 3.5.1 we're going to provide packages also for CentOS 7. We started looking at the CentOS virt SIG a few months ago and we finally decided to join. With me there is also David Caro (in CC), he's member of the oVirt infra and CI team and he's also in oVirt release engineering team. As discussed in the call today, a first thing we're looking at is getting live snapshot capability in qemu-kvm package provided within CentOS. Currently we're delivering qemu-kvm-rhev within oVirt repositories, taking the src.rpm from CentOS repo and rebuilding it with the rhev flag for enabling the capability. Another interesting point for us is providing a live image with oVirt pre-installed. We're now composing oVirt Live[3] iso images using CentOS 6 packages as base also if original kickstart files came from Scientific Linux. We would like to make it fully CentOS based and hopefully move to CentOS 7. We also provide oVirt Node[4] which is also based on CentOS 6 and is a small, robust operating system image using minimal resources while providing the ability to control virtual machines running upon it. Both the spins can take advantage of having packages like qemu-kvm-rhev or in some cases glusterfs or libvirt or other dependencies updates as well as other projects that may rely on the CentOS virt SIG. On the other hand, having latest oVirt RPMs within CentOS will allow CentOS and oVirt users to work with a single repository. We're now looking at CentOS site gathering info about the SIG, how to join and how to contribute. [1] https://fedoraproject.org/wiki/User:Sbonazzo [2] http://www.ovirt.org [3] http://www.ovirt.org/OVirt_Live [4] http://www.ovirt.org/Node Thanks, -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

5 6

CentOS 6 Xen 4.4.1 packages available on virt6-testing
by George Dunlap 07 Jan '15

07 Jan '15

At long last, I've got some beta CentOS 6 4.4.1 packages up on the CBS. Major updates include: * Update to Xen 4.4.1. Also includes all XSAs through 114 * Update to latest blktap 2.5 * Updated libvirt packages (1.2.10), which work well with libxl To use, add the following to a file in /etc/yum.repos.d: [virt-testing] name=CentOS-$releasever - virt-testing baseurl=http://cbs.centos.org/repos/virt6-testing/$basearch/os/ gpgcheck=0 enabled=1 Notes: * git repo with all the changes to xen can be found here: https://github.com/gwd/sig-virt-xen out/virt6/update-4.4.1-4 * The signing infrastructure is not in place, so the binaries are not signed. * xend is now disabled by default. You can enable it by running chkconfig. xend has been removed from the tree entirely in Xen 4.5, so this should (hopefully) serve as a "wake-up-call" for people to begin the transition over to xend. * A lot have things have changed -- please to test this so we can get a good idea what may have broken. -George

3 9

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

virt