search for: 9ed4

...to accomplish even the simplest migration (per every page I can find from both the Fedore Project and Red Hat) I consistently get the following results: root@huey:/tmp# virsh list --all Id Name State ---------------------------------------------------- 9 e7f75b9b-9ed4-4f7e-aa86-e481ab911d6f running - 81c50b5a-24ef-47d5-88ae-16ee7f4f9537 shut off - acd06610-c919-450b-97c8-8e49b9a0d45c shut off root@huey:/tmp# virsh migrate --live --p2p e7f75b9b-9ed4-4f7e-aa86-e481ab911d6f qemu+ssh://10.10.11.204/system error: Failed to open file '/mnt/store01/virt/...

Try creating a blank file on the target system at /mnt/store01/virt/e7f75b9b-9ed4-4f7e-aa86-e481ab911d6f.qcow2 on 'dewey'. Migrations really don't go well when the target disk doesn't exist. I'm not certain why this is, I think the migration feature was mainly built with shared storage in mind. On 9/3/2014 3:05 PM, Gary Hook wrote: > I have been beatin...

On Wed, Sep 3, 2014 at 2:12 PM, Brian Rak <brak@gameservers.com> wrote: > Try creating a blank file on the target system at > /mnt/store01/virt/e7f75b9b-9ed4-4f7e-aa86-e481ab911d6f.qcow2 on 'dewey'. > Yes, tried that before posting. At least, with a simple "touch" command. > Migrations really don't go well when the target disk doesn't exist. I'm > not certain why this is, I think the migration feature was mainl...

...at.com> wrote: > On 09/03/2014 01:05 PM, Gary Hook wrote: > > > > > root@huey:/tmp# virsh migrate --live --p2p > > This command does not default to migrating storage,... > Oh, you mean like this? root@huey:/tmp# virsh migrate --live --p2p --copy-storage-all e7f75b9b-9ed4-4f7e-aa86-e481ab911d6f qemu+ssh://10.10.11.204/system --verbose error: Failed to open file '/mnt/store01/virt/e7f75b9b-9ed4-4f7e-aa86-e481ab911d6f.qcow2': No such file or directory Apologies; I should have used this one in the first place. Too many attempts in the command history.... I...

...cpu Initializing cgroup subsys cpuacct Linux version 3.11.0-desktop+ (tobi at s.klausmann.lan) (gcc version 4.7.2 20130108 [gcc-4_7-branch revision 195012] (SUSE Linux) ) #1 SMP PREEMPT Sun Sep 8 16:00:20 CEST 2013 Command line: BOOT_IMAGE=/boot/vmlinuz-3.11.0-desktop+ root=UUID=85846622-26cb-4096-9ed4-b07b01dd3f92 resume=/dev/disk/by-id/ata-TOSHIBA_MK5059GSXP_32A4C6F1T-part3 splash=silent quiet showopts e820: BIOS-provided physical RAM map: BIOS-e820: [mem 0x0000000000000000-0x000000000009d7ff] usable BIOS-e820: [mem 0x000000000009d800-0x000000000009ffff] reserved BIOS-e820: [mem 0x00000000000e0...

Hey Richard, Could you share the following informations please? 1. gluster volume info <volname> 2. getfattr output of that file from all the bricks getfattr -d -e hex -m . <brickpath/filepath> 3. glustershd & glfsheal logs Regards, Karthik On Thu, Oct 26, 2017 at 10:21 AM, Amar Tumballi <atumball at redhat.com> wrote: > On a side note, try recently released health

On a side note, try recently released health report tool, and see if it does diagnose any issues in setup. Currently you may have to run it in all the three machines. On 26-Oct-2017 6:50 AM, "Amar Tumballi" <atumball at redhat.com> wrote: > Thanks for this report. This week many of the developers are at Gluster > Summit in Prague, will be checking this and respond next

...3184AF5868 (fffc7dcc-bc1a-4061-b63a-1d2396bc550f) on home-client-2 [2017-10-25 10:14:12.506090] W [MSGID: 108015] [afr-self-heal-entry.c:56:afr_selfheal_entry_delete] 0-home-replicate-0: expunging file a3f5a769-8859-48e3-96ca-60a988eb9358/4000230BFEBED57A1825016C12625C8B165F0C8D (44c2de92-905f-4a32-9ed4-350ef14668b5) on home-client-2 [2017-10-25 10:14:12.517084] W [MSGID: 108015] [afr-self-heal-entry.c:56:afr_selfheal_entry_delete] 0-home-replicate-0: expunging file a3f5a769-8859-48e3-96ca-60a988eb9358/7867017B5FCC45144519138A3258A4A957C9233D (3895699f-479f-4753-a0d1-3a3b56e09280) on home-client-2...