search for: xen48

...do I just have to wait for the Xen repository to be updated? Has someone resolved this problem? Regards, G. The following is the output of yum when running yum update: [user at dom0 ~]$ sudo yum update [...] --> Finished Dependency Resolution Error: Package: libvirt-daemon-driver-xen-4.1.0-2.xen48.el7.x86_64 (@centos-virt-xen-48) ?????????? Requires: libvirt.so.0(LIBVIRT_PRIVATE_4.1.0)(64bit) ?????????? Removing: libvirt-libs-4.1.0-2.xen48.el7.x86_64 (@centos-virt-xen-48) ?????????????? libvirt.so.0(LIBVIRT_PRIVATE_4.1.0)(64bit) ?????????? Updated By: libvirt-libs-4.5.0-10.el7_6.3.x86_...

...* base: mirror.dal10.us.leaseweb.net * centosplus: mirror.dal10.us.leaseweb.net * extras: mirror.dal10.us.leaseweb.net * nux-dextop: li.nux.ro * updates: mirror.dal10.us.leaseweb.net Resolving Dependencies --> Running transaction check ---> Package libvirt-bash-completion.x86_64 0:4.1.0-2.xen48.el7 will be updated ---> Package libvirt-bash-completion.x86_64 0:4.5.0-10.el7_6.3 will be an update ---> Package libvirt-client.x86_64 0:4.1.0-2.xen48.el7 will be updated ---> Package libvirt-client.x86_64 0:4.5.0-10.el7_6.3 will be an update ---> Package libvirt-daemon.x86_64 0:4.1.0-...

...to be updated? Has someone resolved this problem? > > Regards, > G. > > The following is the output of yum when running yum update: > > [user at dom0 ~]$ sudo yum update > [...] > --> Finished Dependency Resolution > Error: Package: libvirt-daemon-driver-xen-4.1.0-2.xen48.el7.x86_64 > (@centos-virt-xen-48) > ?????????? Requires: libvirt.so.0(LIBVIRT_PRIVATE_4.1.0)(64bit) > ?????????? Removing: libvirt-libs-4.1.0-2.xen48.el7.x86_64 > (@centos-virt-xen-48) > ?????????????? libvirt.so.0(LIBVIRT_PRIVATE_4.1.0)(64bit) > ?????????? Updated By: libvirt-...

To all, I started the process of updating some of our systems from 7.5 to 7.6. Most of the servers had no problems, but several of the desktops had some difficulties. I was required to perform several yum commands to update as much as possible in the format of yum update a* then b* etc. Then after I got everything updated that would update in this manner and after the use of "rpm -Va

Hello, Recently built RPM package libvirt-4.3.0-1.xen48.el6 ( https://cbs.centos.org/koji/buildinfo?buildID=25235 ) has following issue: When trying to run two or more virus commands (2 or more simultaneous calls to libvirtd) we got virsh stuck. See attached strace log. What could be possible cause? Thanks, -------------- next part -------------- An...

...eems to work fine. Hardware: - Xeons, 24 Cores, 256 GB RAM, 2x 240 GB system-SSDs RAID1, 4x 1,92 TB data-SSDs (no RAID) Software we are using: - CentOS 7.5.1804 - Kernel: 4.9.86-30.el7 @centos-virt-xen-48 - Xen: 4.8.3-5.el7 @centos-virt-xen-48 - libvirt-xen: 4.1.0-2.xen48.el7 @centos-virt-xen-48 - Ceph: 2:12.2.5-0.el7 @Ceph CEPH itself works, Xen too and even libvirt (I'm quite new in this too, normally I use the XL-tools to manage my VMs) ;-) I can manually map an RBD and start a PV-VM via libvirt, after modifying the XML-config and defined th...

On Thu, Jan 21, 2016 at 12:01 PM, Peter <peter at pajamian.dhs.org> wrote: > On 15/01/16 05:57, George Dunlap wrote: >> As mentioned yesterday, Xen 4.6 packages are now available for >> testing. These also include an update to libvirt 1.3.0, in line with >> what's available for CentOS 7. Please test, particularly the upgrade >> if you can, and report any

...year) users have > had. > > On the other hand, explicitly moving to a "xen${VER}" (both for C6 and > C7) would make it simpler for people to step up and maintain older > versions in parallel if anybody wanted to do so. My inclination is towards a naming scheme like xen46, xen48, etc + a meta package that always depends on the latest. It should be more obvious when there's a major upgrade, and those who can't afford a major upgrade can uninstall the meta package. For the record, we have no particular desire for xen 4.4 but haven't done enough testing to say xe...

...d. >> >> On the other hand, explicitly moving to a "xen${VER}" (both for C6 and >> C7) would make it simpler for people to step up and maintain older >> versions in parallel if anybody wanted to do so. > > My inclination is towards a naming scheme like xen46, xen48, etc + a meta package that always depends on the latest. It should be more obvious when > there's a major upgrade, and those who can't afford a major upgrade can uninstall the meta package. BTW, we had a discussion about this particular idea at the Virt SIG meeting, and KB said that dif...

This is a community SIG .. and xenproject.org does NOT release XSAs for 4.2. The goal of Xen4centOS was to use an upstream LTS kernel and update those as required to stay on an LTS. Also to do every second point release of xen (ie, 4.2, 4.4, 4.6). All so we are longer term than upstream, BUT we have supported code from upstream. So, the goal is to use supported code for the longest amount of