similar to: CentOS-virt Digest, Vol 99, Issue 17

First post to this list. I would appreciate some help on this issue. As background, I installed CentOS 7 on a Dell server, and then ran the following commands: yum update http://buildlogs.centos.org/centos/7/virt/x86_64/xen/centos-release-xen-7-11.el7.x86_64.rpm yum --enablerepo=centos-virt-xen-testing update yum --enablerepo=centos-virt-xen-testing install xen Doing that, I was able to

?Not sure if this actually made it to the list the first time.? Here is the SERIAL output (bottom of message after your questions).? Googling the error indicates it's something people ran into a few years back but was supposedly fixed.? Any ideas? I can verify that if I REMOVE the second CPU, it boots into Xen kernel no problem.? The CPU itself doesn't matter, as I can swap either

PJ, I didn't have virsh installed (libvirt-client).? After having installed it, it still didn't see the process: virsh autostart testvm error: failed to connect to the hypervisor error: no valid connection error: Failed to connect socket to '/var/run/libvirt/libvirt-sock': No such file or directory Then, after having installed libvirt, it gives essentially the same error.

Well when the last upgrade 4.2 > 4.4 went live and XM was disabled by default it took many hosts down without warning. 4.4 > 4.6 may cause the same issues. It's a dangerous upgrade for sure. Why can't 4.4 be LTS for C6? as it's the last build with XM. Any XSA patches should not be hard to backport. and maybe the optional xen4.6 for C6. On 21 January 2016 at 13:09, President

?I wrote about this a couple months back.? George asked me to submit to the Xen developers list, but I never had the time due to work demands on getting the new server set up.? In my case, I had to use a different server.? The new motherboard/CPU had no issues with the second CPU.? If you turn off and unplug the second CPU, it will work. Check the archives for my e-mail address and see

Its my impression that as a general rule from RH once some software has been released into a major release any further release of that software does not change major version or fundamental features.. For C6 I would argue Xen 4.2 should stay packaged as xen and Xen 4.4 be packaged as xen44 ... I do not believe that Xen has been released for C7 yet so what ever package version is released

My comment was targeted more at naming than support. I appreciate that there are vanishingly few resources to throw at support. I am glad to see any xen support for C7 and am thankful of all those who are putting in time to make things happen. I try to help out when I can but it is all too infrequently. On 01/21/2016 10:29 AM, Johnny Hughes wrote: > This is a community SIG .. and

?My .02 is to stay the course. ?As a server admin, I want to be able to type things like: yum upgrade php ????not yum upgrade php55-epel-rpmforge-fancy-package Having to remember all the idiosyncrasies of a system is what causes some type of major failure in the future whenever (1) you forget something or (2) someone else has to pick up the box to adminster. -- ?Craig Thompson,

I have released to the master mirror the following packages for Xen4CentOS: b518e3b0fd4f735b34d7784815793cb787283d9029776bd9794cedeb274b9204 kernel-3.18.21-16.el6.x86_64.rpm 4b17373a0ef6806b26d02eb87fc299020beb60b6e31ed08a9c57d30a1410fbe7 kernel-devel-3.18.21-16.el6.x86_64.rpm cacedf6771849f7525145ad4ed7d36a2cad5b49b546173bb7c132b236cb7ac49 kernel-doc-3.18.21-16.el6.noarch.rpm

The following have been added to the virt6-xen-44-testing repo: x86_64: kernel-3.18.21-13.el6.x86_64 kernel-devel-3.18.21-13.el6.x86_64 kernel-firmware-3.18.21-13.el6.noarch kernel-headers-3.18.21-13.el6.x86_64 perf-3.18.21-13.el6.x86_64 src: kernel-3.18.21-13.el6.x86_64 Please test these for a week or so and we will move them into production next week. I am also building this kernel into

On 07/31/2017 02:33 PM, mabi wrote: > Now I understand what you mean the the "-samefile" parameter of > "find". As requested I have now run the following command on all 3 > nodes with the ouput of all 3 nodes below: > > sudo find /data/myvolume/brick -samefile > /data/myvolume/brick/.glusterfs/29/e0/29e0d13e-1217-41cc-9bda-1fbbf781c397 > -ls > >

On 07/31/2017 02:00 PM, mabi wrote: > To quickly resume my current situation: > > on node2 I have found the following file xattrop/indices file which > matches the GFID of the "heal info" command (below is there output of > "ls -lai": > > 2798404 ---------- 2 root root 0 Apr 28 22:51 >

Now I understand what you mean the the "-samefile" parameter of "find". As requested I have now run the following command on all 3 nodes with the ouput of all 3 nodes below: sudo find /data/myvolume/brick -samefile /data/myvolume/brick/.glusterfs/29/e0/29e0d13e-1217-41cc-9bda-1fbbf781c397 -ls node1: 8404683 0 lrwxrwxrwx 1 root root 66 Jul 27 15:43

On 07/30/2017 02:24 PM, mabi wrote: > Hi Ravi, > > Thanks for your hints. Below you will find the answer to your questions. > > First I tried to start the healing process by running: > > gluster volume heal myvolume > > and then as you suggested watch the output of the glustershd.log file > but nothing appeared in that log file after running the above command. >

On 07/31/2017 12:20 PM, mabi wrote: > I did a find on this inode number and I could find the file but only > on node1 (nothing on node2 and the new arbiternode). Here is an ls > -lai of the file itself on node1: Sorry I don't understand, isn't that (XFS) inode number specific to node2's brick? If you want to use the same command, maybe you should try `find

On 07/29/2017 04:36 PM, mabi wrote: > Hi, > > Sorry for mailing again but as mentioned in my previous mail, I have > added an arbiter node to my replica 2 volume and it seem to have gone > fine except for the fact that there is one single file which needs > healing and does not get healed as you can see here from the output of > a "heal info": > > Brick

To quickly resume my current situation: on node2 I have found the following file xattrop/indices file which matches the GFID of the "heal info" command (below is there output of "ls -lai": 2798404 ---------- 2 root root 0 Apr 28 22:51 /data/myvolume/brick/.glusterfs/indices/xattrop/29e0d13e-1217-41cc-9bda-1fbbf781c397 As you can see this file has inode number 2798404, so I ran

Hi Ravi, Thanks for your hints. Below you will find the answer to your questions. First I tried to start the healing process by running: gluster volume heal myvolume and then as you suggested watch the output of the glustershd.log file but nothing appeared in that log file after running the above command. I checked the files which need to be healing using the "heal <volume> info"

I did a find on this inode number and I could find the file but only on node1 (nothing on node2 and the new arbiternode). Here is an ls -lai of the file itself on node1: -rw-r--r-- 1 www-data www-data 32 Jun 19 17:42 fileKey As you can see it is a 32 bytes file and as you suggested I ran a "stat" on this very same file through a glusterfs mount (using fuse) but unfortunately nothing

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