картопостроитель устройства на RHEL6, не могущем создать devs для логического тома LVM
QtCurve является механизмом темы, не темой в и себя, хотя он действительно идет с набором по умолчанию тем. Темами являются просто текстовые файлы, которые определяют, как Вы хотите, чтобы каждый компонент посмотрел, например, полоса прокрутки, и т.д. Если Вы переходите к странице настроек KDE для Появления Приложения-> Стиль, Вы видите, установлен ли QtCurve путем наблюдения, перечислен ли он в выпадающем поле около вершины окна, маркировал "widget style". В противном случае установите, это через Кв. - добирается или что бы то ни было. После того как это установлено и появляется в Стиле выпадающее поле, выберите его, затем нажмите "настраивать" кнопку направо от выпадающего. В окне, которое появляется, можно или выбрать тему, чтобы запуститься с или только начать изменять текущую тему (названный "текущим"). На левой стороне окна существует большой массив выбора выбрать из, где можно изменить все о выбранной теме. Это является немного громоздким для наблюдения изменений, поскольку необходимо продолжать нажимать самый верхний объект "предварительный просмотр", чтобы осмотреть изменения и видеть, являются ли они также симпатией. Я верное желание там было мгновенным полем предварительного просмотра, которое держит быть в курсе, поскольку Вы изменяете вещи, но еще. В любом случае, когда Вы удовлетворены, избранное "Сохранение" чуть ниже "предварительных установок" выпадающее поле около вершины окна, и выбираете новое название своего шедевра.:) QTcurve удивительно настраивается. Текстовые файлы заканчивают тем, что были депонированы в: ~.kde/share/apps/QtCurve, но можно использовать кнопку "экспорта" для сохранения от работы для резервного копирования. Импорт подобен, с помощью включенной кнопки "импорта".
Похоже, что многопутевый режим на гипервизоре отказывается обновлять свои карты для размеров LUN.
Первоначально размер этого LUN был 28 ГБ, а позже он был увеличен до 48 ГБ в массиве хранения.
Согласно информации VG, это 48 Гбайт, а на самом деле этот диск - 48 Гбайт, но многопутевый режим не обновляется и думает, что это все еще 28 Гбайт.
Многопутевое цепляние за 28G:
# multipath -l 350002acf962421ba
350002acf962421ba dm-17 3PARdata,VV
size=28G features='1 queue_if_no_path' hwhandler='0' wp=rw
`-+- policy='round-robin 0' prio=0 status=active
|- 8:0:0:22 sdt 65:48 active undef running
|- 10:0:0:22 sdbh 67:176 active undef running
|- 7:0:0:22 sddq 71:128 active undef running
|- 9:0:0:22 sdfb 129:208 active undef running
|- 8:0:1:22 sdmz 70:432 active undef running
|- 7:0:1:22 sdoj 128:496 active undef running
|- 10:0:1:22 sdop 129:336 active undef running
|- 9:0:1:22 sdqm 132:352 active undef running
|- 7:0:2:22 sdxh 71:624 active undef running
|- 8:0:2:22 sdzy 131:704 active undef running
|- 10:0:2:22 sdaab 131:752 active undef running
|- 9:0:2:22 sdaed 66:912 active undef running
|- 7:0:3:22 sdakm 132:992 active undef running
|- 10:0:3:22 sdall 134:880 active undef running
|- 8:0:3:22 sdamx 8:1232 active undef running
`- 9:0:3:22 sdaqa 69:1248 active undef running
Реальный размер диска в хранилище:
# showvv ALHIDB_SNP_001
-Rsvd(MB)-- -(MB)-
Id Name Prov Type CopyOf BsId Rd -Detailed_State- Adm Snp Usr VSize
4098 ALHIDB_SNP_001 snp vcopy ALHIDB_SNP_001.ro 5650 RW normal -- -- -- 49152
Просто чтобы убедиться, что у меня правильный диск:
# showvlun -showcols VVName,VV_WWN| grep -i 0002acf962421ba
ALHIDB_SNP_001 50002ACF962421BA
И VG думает, что его 48G
--- Volume group ---
VG Name vg_ALHINT
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 30
VG Access read/write
VG Status exported/resizable
MAX LV 0
Cur LV 5
Open LV 0
Max PV 0
Cur PV 1
Act PV 1
VG Size 48.00 GiB
PE Size 4.00 MiB
Total PE 12287
Alloc PE / Size 12287 / 48.00 GiB
Free PE / Size 0 / 0
VG UUID qqZ9Vi-5Ob1-R6zb-YeWa-jDfg-9wc7-E2wsem
Когда я повторно сканирую HBA для новых дисков и перенастроить multipthing, диск по-прежнему отображает 28G, поэтому я попробовал сделать это без изменений:
# multipathd -k'resize map 350002acf962421ba'
Версии:
lvm2-2.02.56-8.100.3.el5
device-mapper-multipath-libs-0.4.9-46.100.5.el5
Временное решение Поскольку я не мог придумать решения, я сделал следующее: {{1 }} Я не писал ранее, что запускаю OVM 3.2 поверх, поэтому часть моего решения будет включать OVM. i) Завершение работы гостей на Xen через OVM. ii) Удаление дисков {{ 1}} iii) Удаление LUN из OVM iv) Отсутствие LUN из гипервизоров. v) Повторное сканирование хранилища OVM. vi) Подождите 30 минут;) vii) Представьте мои диски гипервизорам с разными идентификаторами LUN. viii) Повторное сканирование хранилища OVM
И теперь, как ни странно, я вижу диски 48G.
# multipath -l 350002acf962421ba
350002acf962421ba dm-18 3PARdata,VV
size=48G features='1 queue_if_no_path' hwhandler='0' wp=rw
`-+- policy='round-robin 0' prio=0 status=active
|- 9:0:0:127 sdt 65:48 active undef running
|- 9:0:1:127 sdbh 67:176 active undef running
|- 9:0:2:127 sddo 71:96 active undef running
|- 9:0:3:127 sdfb 129:208 active undef running
|- 10:0:3:127 sdmz 70:432 active undef running
|- 10:0:0:127 sdoh 128:464 active undef running
|- 10:0:1:127 sdop 129:336 active undef running
|- 10:0:2:127 sdqm 132:352 active undef running
|- 7:0:1:127 sdzu 131:640 active undef running
|- 7:0:0:127 sdxh 71:624 active undef running
|- 7:0:3:127 sdaed 66:912 active undef running
|- 7:0:2:127 sdaab 131:752 active undef running
|- 8:0:0:127 sdakm 132:992 active undef running
|- 8:0:1:127 sdall 134:880 active undef running
|- 8:0:2:127 sdamx 8:1232 active undef running
`- 8:0:3:127 sdaqa 69:1248 active undef running
См. devices.txt в документации ядра: основной 202 - «виртуальное блочное устройство Xen», основной 253 - LVM / устройство сопоставления .
Все ваши dm-x устройства - 253: n ; они просто указывают на 202: n .
Сообщение об ошибке ясное:
device-mapper: table: 253:7: xvdb too small for target: start=58714112, len=41943040, dev_size=58720256
Похоже, в устройстве XEN произошли изменения. Ваш vg_ALHPRD-oradata не может быть загружен, потому что он пытается получить доступ к пространству хранения на 202: 16 , которого просто не существует.