similar to: Plan for libguestfs 1.28

On Wed, Oct 08, 2014 at 08:11:16AM +0000, VONDRA Alain wrote: > Hi, > I meet an amazing issue, when I convert a raw file to the oVirt environment using virt-v2v. > All seems to work fine, my VM is composed of 9 disks, the processes > finishes without any trouble, the files are well present in the > right import volume, but only the first system disk appear un my > oVirt Import

Hi, I meet an amazing issue, when I convert a raw file to the oVirt environment using virt-v2v. All seems to work fine, my VM is composed of 9 disks, the processes finishes without any trouble, the files are well present in the right import volume, but only the first system disk appear un my oVirt Import VM. I've retried twice and had the same issue . Here the results of the conversion : [

I've tried this issue and could reproduce this issue: 1.Convert a guest with 2 disks to rhev. # virt-v2v -ic xen+ssh://10.66.106.64 -o rhev -os 10.66.90.115:/vol/v2v_auto/auto_export rhel6.6-i386-hvm -on 2disk-test -of qcow2 [ 0.0] Opening the source -i libvirt -ic xen+ssh://10.66.106.64 rhel6.6-i386-hvm [ 16.0] Creating an overlay to protect the source from being modified [ 47.0]

On Wed, Oct 15, 2014 at 03:23:39PM +0000, VONDRA Alain wrote: > I see only qemu-img consumming some CPU and MEM : > > 25897 qemu 20 0 5825976 2,429g 4368 S 5,6 32,2 603:09.34 qemu-kvm That's qemu, not qemu-img. > I have indeed, some nfs errors : > > [475747.296041] nfs: server 192.203.100.247 not responding, still trying > [475747.772022] nfs: server

I was hoping that it works, but the conversion hanged at the 7th /9 disk 57,03% since 1.30 AM... [19351,0] Copying disk 7/9 to /tmp/v2v.UgUPSx/0a6404e0-2857-45e4-9322-c1ada5ae13fb/images/0123ddcd-f88d-43d0-b836-2cabe57beac3/d0fe6d79-b846-41ca-ac94-835b97488685 (raw) target_file =

Hi Matt, The files might be in split brain. Could you please send the outputs of these? gluster volume info <volname> gluster volume heal <volname> info And also the getfattr output of the files which are in the heal info output from all the bricks of that replica pair. getfattr -d -e hex -m . <file path on brick> Thanks & Regards Karthik On 16-Oct-2017 8:16 PM,

OK, so here?s my output of the volume info and the heal info. I have not yet tracked down physical location of these files, any tips to finding them would be appreciated, but I?m definitely just wanting them gone. I forgot to mention earlier that the cluster is running 3.12 and was upgraded from 3.10; these files were likely stuck like this when it was on 3.10. [root at tpc-cent-glus1-081017 ~]#

Hi Matt, Run these commands on all the bricks of the replica pair to get the attrs set on the backend. On the bricks of first replica set: getfattr -d -e hex -m . <brick path>/.glusterfs/10/86/ 108694db-c039-4b7c-bd3d-ad6a15d811a2 On the fourth replica set: getfattr -d -e hex -m . <brick path>/.glusterfs/ e0/c5/e0c56bf7-8bfe-46ca-bde1-e46b92d33df3 Also run the "gluster volume

Attached is the heal log for the volume as well as the shd log. >> Run these commands on all the bricks of the replica pair to get the attrs set on the backend. [root at tpc-cent-glus1-081017 ~]# getfattr -d -e hex -m . /exp/b1/gv0/.glusterfs/10/86/108694db-c039-4b7c-bd3d-ad6a15d811a2 getfattr: Removing leading '/' from absolute path names # file:

I've been following this particular thread as I have a similar issue (RAID6 array failed out with 3 dead drives at once while a 12 TB load was being copied into one mounted space - what a mess) I have >700K GFID entries that have no path data:Example:getfattr -d -e hex -m . .glusterfs/00/00/0000a5ef-5af7-401b-84b5-ff2a51c10421# file: .glusterfs/00/00/0000a5ef-5af7-401b-84b5-

In my case I was able to delete the hard links in the .glusterfs folders of the bricks and it seems to have done the trick, thanks! From: Karthik Subrahmanya [mailto:ksubrahm at redhat.com] Sent: Monday, October 23, 2017 1:52 AM To: Jim Kinney <jim.kinney at gmail.com>; Matt Waymack <mwaymack at nsgdv.com> Cc: gluster-users <Gluster-users at gluster.org> Subject: Re:

On Tue, Oct 07, Richard W.M. Jones wrote: > It has been an amazing 6½ months since the last stable release of > libguestfs. > > I'd like to plan a new 1.28 release soon. > > Please follow-up if there are features / blockers / bugs that need to > be addressed for 1.28. I see master failing in my SLE11 builds since some time. Currently it fails with a syntax error. Are

Hi Jim, Can you check whether the same hardlinks are present on both the bricks & both of them have the link count 2? If the link count is 2 then "find <brickpath> -samefile <brickpath/.glusterfs/<first two bits of gfid>/<next 2 bits of gfid>/<full gfid>" should give you the file path. Regards, Karthik On Tue, Oct 24, 2017 at 3:28 AM, Jim Kinney

I'm not so lucky. ALL of mine show 2 links and none have the attr data that supplies the path to the original. I have the inode from stat. Looking now to dig out the path/filename from xfs_db on the specific inodes individually. Is the hash of the filename or <path>/filename and if so relative to where? /, <path from top of brick>, ? On Mon, 2017-10-23 at 18:54 +0000, Matt Waymack

Hey Matt, >From the xattr output, it looks like the files are not present on the arbiter brick & needs healing. But on the parent it does not have the pending markers set for those entries. The workaround for this is you need to do a lookup on the file which needs heal from the mount, so it will create the entry on the arbiter brick and then run the volume heal to do the healing. Follow

Hi Jim & Matt, Can you also check for the link count in the stat output of those hardlink entries in the .glusterfs folder on the bricks. If the link count is 1 on all the bricks for those entries, then they are orphaned entries and you can delete those hardlinks. To be on the safer side have a backup before deleting any of the entries. Regards, Karthik On Fri, Oct 20, 2017 at 3:18 AM, Jim

I have 14,734 GFIDS that are different. All the different ones are only on the brick that was live during the outage and concurrent file copy- in. The brick that was down at that time has no GFIDs that are not also on the up brick. As the bricks are 10TB, the find is going to be a long running process. I'm running several finds at once with gnu parallel but it will still take some time.

On Thu, Oct 09, 2014 at 11:49:59AM +0200, Olaf Hering wrote: > On Tue, Oct 07, Richard W.M. Jones wrote: > > > It has been an amazing 6½ months since the last stable release of > > libguestfs. > > > > I'd like to plan a new 1.28 release soon. > > > > Please follow-up if there are features / blockers / bugs that need to > > be addressed for

Hello list, i'm going to try very hard not to rant here, but i've been trying to get Samba working for 3 days, and it's just not happening. Let me start from the beginning. i'm just a lowly Windows admin but i've been doing this for 10 years, so i'm pretty sure i know what i'm doing (present situation excepted, clearly). i've got RedHat AS4 and a primarily

Ok Thanks Richard, I'll try it ! Alain VONDRA Chargé d'exploitation des Systèmes d'Information Direction Administrative et Financière +33 1 44 39 77 76 UNICEF France 3 rue Duguay Trouin 75006 PARIS www.unicef.fr -----Message d'origine----- De : Richard W.M. Jones [mailto:rjones@redhat.com] Envoyé : mercredi 8 octobre 2014 17:23 À : VONDRA Alain Cc : libguestfs@redhat.com