[sheepdog] some problem about sheepdog
*Hi*
*Recently, I met some problems in learning sheepdog.*
*I have 2 machines. They information follow:*
*Node1[10.198.3.141]*
eth1 Link encap:Ethernet HWaddr FC:48:EF:2E:47:2B
inet addr:10.198.3.141 Bcast:10.198.3.191 Mask:255.255.255.192
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:166041 errors:0 dropped:0 overruns:0 frame:0
TX packets:272247 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:81563807 (77.7 MiB) TX bytes:35527000 (33.8 MiB)
loLink encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:489642 errors:0 dropped:0 overruns:0 frame:0
TX packets:489642 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:54504426 (51.9 MiB) TX bytes:54504426 (51.9 MiB)
*Node2[10.198.4.108]*
eth1 Link encap:Ethernet HWaddr FC:48:EF:2E:69:8B
inet addr:10.198.4.108 Bcast:10.198.4.127 Mask:255.255.255.192
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:113220 errors:0 dropped:0 overruns:0 frame:0
TX packets:66017 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:114656591 (109.3 MiB) TX bytes:18070118 (17.2 MiB)
loLink encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:77863 errors:0 dropped:0 overruns:0 frame:0
TX packets:77863 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:9968948 (9.5 MiB) TX bytes:9968948 (9.5 MiB)
*They are not in the same ethernet switch.The corosync conf follow:*
# Please read the corosync.conf.5 manual page
compatibility: whitetank
totem {
version: 2
secauth: off
threads: 0
interface {
ringnumber: 0
bindnetaddr: 192.168.1.1
mcastaddr: 239.255.1.1
mcastport: 5405
ttl: 1
}
}
logging {
fileline: off
to_stderr: no
to_logfile: yes
to_syslog: yes
logfile: /var/log/cluster/corosync.log
debug: off
timestamp: on
logger_subsys {
subsys: AMF
debug: off
}
}
amf {
mode: disabled
}
*Two confs is same. My issue is that they not in the same cluster.*
*Node1 input *dog node list
Id Host:Port V-Nodes Zone
0 127.0.0.1:7000 64 16777343
Node2 input dog node list
Id Host:Port V-Nodes Zone
0 127.0.0.1:7000 64 16777343
*Only two nodes in the same **ethernet switch can in the same cluster?*
*help me,please...*
--
sheepdog mailing list
sheepdog@lists.wpkg.org
http://lists.wpkg.org/mailman/listinfo/sheepdog
Re: [sheepdog] some problem about sheepdog
Your Host are 10.198.3.141 and 10.198.4.108 and
not in the same IP Subnet. (Are you able to ping
these host among each other at all?)
Your corosync listen to 192.168.1.1, which seem
to be no local interface on your hosts.
And your sheep processes listen to 127.0.0.1 which
is the loopback interface.
My advise, put your both hosts in the same IP
subnet, configure corosync to bind to these
Interfaces and if it dosnt work, post the
command you start sheep daemon with...
Cheers
Bastian
Am 2014-08-01 07:03, schrieb gzh1992n:
*Hi*
*Recently, I met some problems in learning sheepdog.*
*I have 2 machines. They information follow:*
*Node1[10.198.3.141]*
eth1 Link encap:Ethernet HWaddr FC:48:EF:2E:47:2B
inet addr:10.198.3.141 Bcast:10.198.3.191
Mask:255.255.255.192
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:166041 errors:0 dropped:0 overruns:0 frame:0
TX packets:272247 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:81563807 (77.7 MiB) TX bytes:35527000 (33.8 MiB)
loLink encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:489642 errors:0 dropped:0 overruns:0 frame:0
TX packets:489642 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:54504426 (51.9 MiB) TX bytes:54504426 (51.9 MiB)
*Node2[10.198.4.108]*
eth1 Link encap:Ethernet HWaddr FC:48:EF:2E:69:8B
inet addr:10.198.4.108 Bcast:10.198.4.127
Mask:255.255.255.192
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:113220 errors:0 dropped:0 overruns:0 frame:0
TX packets:66017 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:114656591 (109.3 MiB) TX bytes:18070118 (17.2 MiB)
loLink encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:77863 errors:0 dropped:0 overruns:0 frame:0
TX packets:77863 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:9968948 (9.5 MiB) TX bytes:9968948 (9.5 MiB)
*They are not in the same ethernet switch.The corosync conf follow:*
# Please read the corosync.conf.5 manual page
compatibility: whitetank
totem {
version: 2
secauth: off
threads: 0
interface {
ringnumber: 0
bindnetaddr: 192.168.1.1
mcastaddr: 239.255.1.1
mcastport: 5405
ttl: 1
}
}
logging {
fileline: off
to_stderr: no
to_logfile: yes
to_syslog: yes
logfile: /var/log/cluster/corosync.log
debug: off
timestamp: on
logger_subsys {
subsys: AMF
debug: off
}
}
amf {
mode: disabled
}
*Two confs is same. My issue is that they not in the same cluster.*
*Node1 input *dog node list
Id Host:Port V-Nodes Zone
0 127.0.0.1:7000 64 16777343
Node2 input dog node list
Id Host:Port V-Nodes Zone
0 127.0.0.1:7000 64 16777343
*Only two nodes in the same **ethernet switch can in the same cluster?*
*help me,please...*
--
sheepdog mailing list
sheepdog@lists.wpkg.org
http://lists.wpkg.org/mailman/listinfo/sheepdog
Re: [sheepdog] [PATCH v2 0/7] revive VDI locking mecahnism
2014-07-30 9:29 GMT+02:00 Hitoshi Mitake mitake.hito...@lab.ntt.co.jp: Valerio, Fabian, could you test this series? It seems to work fine. I notice the warning message vary a bit on the node with the latest qemu version. root@test005:~# qemu-system-x86_64 -enable-kvm -drive file=sheepdog:test -k it -vnc :1 qemu-system-x86_64: -drive file=sheepdog:test: cannot get vdi info, VDI isn't locked, test 0 qemu-system-x86_64: -drive file=sheepdog:test: could not open disk image sheepdog:test: Input/output error root@valerio:~# qemu-system-x86_64 -enable-kvm -drive file=sheepdog:test -k it -vnc :1 qemu-system-x86_64: -drive file=sheepdog:test: could not open disk image sheepdog:test: cannot get vdi info, VDI isn't locked, test 0 root@valerio:~# qemu-system-x86_64 -version QEMU emulator version 2.0.95, Copyright (c) 2003-2008 Fabrice Bellard root@test005:~# qemu-system-x86_64 -version QEMU emulator version 1.5.50, Copyright (c) 2003-2008 Fabrice Bellard Sheepdog daemon version 0.8.50 This is what I see in sheep.log Aug 01 10:27:28 INFO [main] cluster_lock_vdi_main(1334) node: IPv4 ip:192.168.2.27 port:7000 is locking VDI: 7c2b25 Aug 01 10:27:28 INFO [main] lock_vdi(297) VDI 7c2b25 is locked Aug 01 10:28:12 INFO [main] cluster_lock_vdi_main(1334) node: IPv4 ip:192.168.2.45 port:7000 is locking VDI: 7c2b25 Aug 01 10:28:12 INFO [main] lock_vdi(301) VDI 7c2b25 is already locked Aug 01 10:28:12 ERROR [main] cluster_lock_vdi_main(1337) locking 7c2b25failed -- sheepdog mailing list sheepdog@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/sheepdog
Re: [sheepdog] [PATCH v2 0/7] revive VDI locking mecahnism
I've been testing also kill and kill -9.
With kill the lock gets removed.
With kill -9 it doens't (as expected).
'vdi lock force-unlock' works fine but I notices 2 things:
1) the syntax doesn't mentions 'vdiname'
dog vdi lock {list|force-unlock} [-a address] [-p port] [-h] [-t]
it should be
dog vdi lock {list|force-unlock} [-a address] [-p port] [-h] [-t] vdiname
2) if I don't write any vdi name, it crashes:
dog vdi lock force-unlock
dog exits unexpectedly (Segmentation fault).
dog.c:374: crash_handler
/lib/x86_64-linux-gnu/libpthread.so.0(+0xf02f) [0x7f834b7b402f]
/lib/x86_64-linux-gnu/libc.so.6(+0x7f5b9) [0x7f834b0785b9]
treeview.c:63: find_vdi_with_name
vdi.c:2763: lock_force_unlock
common.c:262: do_generic_subcommand
dog.c:572: main
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xfc) [0x7f834b017eec]
dog() [0x4041a8]
Segmentation fault
--
sheepdog mailing list
sheepdog@lists.wpkg.org
http://lists.wpkg.org/mailman/listinfo/sheepdog
Re: [sheepdog] [PATCH v2 0/7] revive VDI locking mecahnism
I tried to vdi check a locked vdi. vdi check ignore the lock. I remember from previous discussions that we must not run vdi check on used vdi. So I guess vdi check should exit with the same qemu warning message. If the guest is not running (because of qemu crash etc) but the lock is active, it's administrator duty to remove it before running the check. What do you think about it? -- sheepdog mailing list sheepdog@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/sheepdog
