Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
With -vvv on pvcreate - this is what it reports...
/dev/drbd0: Added to device cache
/dev/drbd0: open failed: Wrong medium type
/dev/drbd0: Skipping: open failed
/dev/drbd0: Skipping (cached)
Jim
On Fri, 2006-11-24 at 17:28 +0000, James Vanns wrote:
> This maybe slightly off-topic as I am unsure if this is a DRBD problem
> or not (I am using LVM fine locally...)
>
> OK, so now I can't create an LVM PV on a DRBD device:
>
> [root at jimmy ~]# pvcreate -M 2 --setphysicalvolumesize 150G -v /dev/drbd0
> Loaded external locking library /usr/lib/liblvm2clusterlock.so
> Wiping cache of LVM-capable devices
> Wiping internal VG cache
> Device /dev/drbd0 not found (or ignored by filtering).
>
> It (/dev/drbd0) is not ignored by filtering (its explicitly 'accepted'
> in lvm.conf just to be sure) and it does exist:
>
> [root at jimmy ~]# ls -lath /dev/drbd?
> brw-r----- 1 root disk 147, 1 Nov 24 16:05 /dev/drbd1
> brw-r----- 1 root disk 147, 0 Nov 24 13:46 /dev/drbd0
>
> [root at jimmy ~]# ls -lath /sys/block/drbd?
> /sys/block/drbd1:
> total 0
> drwxr-xr-x 4 root root 0 Nov 24 17:25 .
> -r--r--r-- 1 root root 4.0K Nov 24 17:25 removable
> -r--r--r-- 1 root root 4.0K Nov 24 17:25 size
> -r--r--r-- 1 root root 4.0K Nov 24 17:25 stat
> --w------- 1 root root 4.0K Nov 24 17:25 uevent
> -r--r--r-- 1 root root 4.0K Nov 24 16:05 range
> lrwxrwxrwx 1 root root 0 Nov 24 16:05 subsystem -> ../../block
> -r--r--r-- 1 root root 4.0K Nov 24 16:05 dev
> drwxr-xr-x 27 root root 0 Nov 24 16:05 ..
> drwxr-xr-x 2 root root 0 Nov 24 16:05 holders
> drwxr-xr-x 2 root root 0 Nov 24 16:05 slaves
>
> /sys/block/drbd0:
> total 0
> drwxr-xr-x 4 root root 0 Nov 24 17:23 .
> -r--r--r-- 1 root root 4.0K Nov 24 17:23 range
> -r--r--r-- 1 root root 4.0K Nov 24 17:23 removable
> -r--r--r-- 1 root root 4.0K Nov 24 17:23 size
> -r--r--r-- 1 root root 4.0K Nov 24 17:23 stat
> lrwxrwxrwx 1 root root 0 Nov 24 17:23 subsystem -> ../../block
> --w------- 1 root root 4.0K Nov 24 17:23 uevent
> -r--r--r-- 1 root root 4.0K Nov 24 16:16 dev
> drwxr-xr-x 27 root root 0 Nov 24 16:05 ..
> drwxr-xr-x 2 root root 0 Nov 24 13:46 holders
> drwxr-xr-x 2 root root 0 Nov 24 13:46 slaves
>
> Any ideas?
>
> Jim
>
> On Thu, 2006-11-23 at 23:13 +0100, Håkan wrote:
> > James Vanns wrote:
> > > What are your thoughts on the following setup?
> > >
> > > 2x physical nodes - identical
> > > DRBD latest 'pre' 0.8 source
> > > Fedora Core 6 host OS/dom0 (on both nodes)
> > > Crossover cable between the two nodes with 10.0.0.1, 10.0.0.2
> > > respectively purely for DRBD chatter.
> > > Metadata (of DRBD) stored on a separate disk on each machine
> > > (/dev/sda5).
> > > DRBD 'source' drive is /dev/sdb and target drive is /dev/drbd0
> > >
> > This is almost exactly my setup as well. Seems reasonable.
> >
> >
> >
> > > ...Therefore Xen1 will never write to the same LV as Xen2. But then there
> > > is the question of LVM meta data etc. logs and caches etc. of all these
> > > layers - how do you think DRBD will handle it without the use of OCFS or
> > > GFS as the choice of FS on the Xen LV drives
> > >
> > DRBD handles it just fine, since it's working on a block device layer. I
> > use ext3 with good results.
> > I compile my own LVM, device-mapper and cluster suite, to get it the way
> > i want it, with clvmd and all. This ensures that there will be no
> > problem with meta data and such.
> > DRBD does a good job here, and it works quite good with the new pre6.
> > Nothing much to add there.
> > My setup works well with migration, which is why I use drbd in the first
> > place.
> >
> >
> > /Håkan
> >
--
James Vanns
Systems Programmer
Framestore CFC Ltd.