[CentOS-virt] LVM Lockout SIMPLER
Ben M.
centos at rivint.com
Thu Oct 15 02:53:00 UTC 2009
Give what I wrote before, after boot up I want this:
[root at ThisXen1 ~]# dmraid -s
*** Active Set
name : nvidia_fbacacad
size : 293046656
stride : 128
type : mirror
status : ok
subsets: 0
devs : 2
spares : 0
*** Set
name : nvidia_hfcehfah
size : 1250263680
stride : 128
type : mirror
status : ok
subsets: 0
devs : 2
spares : 0
To have BOTH sets Active so that my LVs for my domUs are up.
nvidia_hfcehfah is not active.
If I type dmraid -ay, they will both be active. I can't find a grub.conf
kernel argument to do that. Which would seem "safer" than the fstab
entry and have a more "graceful" failure, likely limited to just domUs.
Ben M. wrote:
> > It may be easier to help if you explain where you're at, where you
> want to be, and what you did to make it worse. :) The dmraid and LVM
> layouts would help, as well as the symptoms you're having.
>
>
> This is all "Standard CentOS 5.3" install, with X Windows and XFCE4
> loaded afterwards and initiated as command line, not as service. No
> repos other than 'stock'.
>
> I use virt-manager to start of domUs quickly and then edit them to
> polish off.
>
> Scenario
> ========
> Small machine, a test case, but will be using pretty much the same for
> the next few builds, only twice the capacity. 4cpu cores, 16gig ram.
>
> - 2X AMD 2212s (2 core by two)
> - Tyan Board, ECC Mem 16gig.
> - MCP55 nvidia fake raid (I have had good fortune with this chipset).
> - Pair of 160g WD Velocipaptors, RAID1 on the BIOS, dmraid on OS.
> - DVD plus 160gig pata drive on IDE for odds and ends. 160gig
> - ACPI Manufacturer's Table set to Off in BIOS, was troublesome.
>
> Essentially everything is good with exception of a couple of xm dmesg
> WSMR and NMI warnings that are not fatal.
>
> I'm ran decently with above. Fine on domU's with CentOS x86, not sure on
> x64 but don't need it yet. Have Windows 2008 Web Server (x86 version,
> not x64) "running" okay with GPLPV. I say okay because I must be getting
> some sloppy shutdowns due to some Registry Hive and corruption errors.
> It could be that W2K8 is not the stable creature that I found in W2k3.
> It certainly is loaded with an incredible amount of crap that is useless
> and some of which seems to be serving DRM more than system needs. They
> should have called it Vista Server, heh.
>
> Then instability caused by addition of another RAID1 set.
>
>
> Situation (Where I'm at)
> =========
> I add in a pair of WD 640g Caviars, not RE types, which I modded a tiny
> bit with WDTyler utility to make them more "raid ready." It's a minor
> trick, but gives you a little more assurance.
>
> They show up in /dev as sd(x)s, but not in /dev/mapper with the nvidia_
> handle. I type dmraid -ay and there they are, but not auto-magically
> like the first pair do at boot. I don't see a conf file to make this happen
>
> Mistake 1:
> ==========
> Never mount to the "primary" device in mapper, only the ones that end
> with "p1" "p2" etc.
>
> Mistake 2:
> ==========
> Never pvextend a disk into the same vggroup as your / (root). I wanted
> this so I could migrate the extents off of the test domUs that were
> good. That would have been the easy, and slick way.
>
> Probably Mistake 3:
> ===================
> Don't pvextend hard devices at all. Keep VolumeGroups dedicated
> PhysicalVolumes that don't cross over. My initial raidset was 'vg00' and
> the added on pata drive 'vg01' and I was fine with that.
>
> The loss of a LogicalVolume that is on a dropped device is rather
> inelegant. I have not found out what happens if all is contained by a
> dedicated Volume Group (VG) to a dedicated device (PV), but if a
> LogicalVolume (LV) is on another device (PV) than the rest of the LVs
> within that VG then Xen, dom0 and all the domUs are non-booting and
> inaccessible via IP protocols.
>
> fstab entry for a /dev/mapper/raid_device(PartNo)/LVname kills the boot
> if the LV isn't there, whether by hardware drop, or non-initialization
> by dmraid.
>
> All seems fine on one dmraid device box. It is two Raid1s where I am
> hitting a wall. I'm going to try, right now, one more time, with the
> additional raid set, on its own PV/VG setup (e.g. vg02).
>
>
> Where I was:
> Stable with 1 Raid1 set, running out of space.
>
> Where I am:
> Unstable after attempting to add additional Raid1 set.
>
> Where I want to be:
> 2 Raid1 sets
> 1 "miscellaneous" pata
> and stable.
>
> I am going to try one more time to add the additional RAID1 set with own
> PV and VG and figure out how to move existing domUs to it after I bring
> it to office (150 miles away). I hope I don't have to run back and forth
> to go on the console.
>
>
>
>
> Christopher G. Stach II wrote:
>> ----- "Ben M." <centos at rivint.com> wrote:
>>
>>>> The metadata should get everything loaded for you out of the
>>> initrd,
>>> > as long as it has all of the necessary RAID level drivers in it.
>>>
>>> I wish. This has been agonizing and it looks like I am going to be
>>> installing a kludge. I'm going to have to accelerate the build of the
>>> next ones. I don't have a warm and fuzzy on this machine anymore.
>> It may be easier to help if you explain where you're at, where you want to be, and what you did to make it worse. :) The dmraid and LVM layouts would help, as well as the symptoms you're having.
>>
>
> _______________________________________________
> CentOS-virt mailing list
> CentOS-virt at centos.org
> http://lists.centos.org/mailman/listinfo/centos-virt
>
More information about the CentOS-virt
mailing list