файл политики, загружаемый в ядро, находится по адресу
/etc/selinux/<'SELINUXTYPE'>/policy/policy.<'version'>.
Где <'SELINUXTYPE'> — имя политики, указанное в файле конфигурации SELinux /etc/selinux/config, а <'version'> — версия политики SELinux.
Ниже показан пример файла /etc/selinux/config, где запись SELINUXTYPE=targeted определяет имя политики, которое будет использоваться для поиска и загрузки активной политики:
SELINUX=permissive
SELINUXTYPE=targeted
В приведенном выше примере фактический двоичный файл политики будет расположен в /etc/selinux/targeted/policy и будет называться policy.29 (, так как версия 29 поддерживается F -20):
/etc/selinux/targeted/policy/policy.29
В вашем сценарии vgexport
/vgimport
на самом деле не нужны, именно потому, что вы уже знаете существующие имена VG на новой машине.
Чтобы переименовать виртуальную группу в старой системе, вам, скорее всего, потребуется сначала размонтировать и деактивировать ее, а поскольку в ней нет конфликта имен, вам не нужно использовать UUID виртуальной группы вместо старого. имя (хотя можешь, если хочешь):
umount /mount-point/
vgchange -an Old_VG_Name
vgrename Old_VG_Name New_VG_Name
vgchange -ay New_VG_Name
<edit /etc/fstab to replace Old_VG_Name with New_VG_Name>
mount /mount-point
Перед снятием дисков:
<edit /etc/fstab to comment out/remove the line for the /mount-point/>
umount /mount-point/
vgchange -an Old_VG_Name # technically the shutdown procedure would do this too
Вы даже можете -отключить диски, если сделаете это после деактивации VG:
echo 1 > /sys/block/sdc/device/delete
echo 1 > /sys/block/sdd/device/delete
Это говорит ядру подготовиться к неизбежному физическому отключению этих устройств. (Если вы используете паравиртуализированные драйверы на виртуальной машине, узел виртуализации может отправить предупреждающее сообщение драйверу перед горячим -удалением виртуального диска, что делает этот шаг ненужным.)
После переноса дисков в новую систему обычная процедура запуска системы -в большинстве дистрибутивов автоматически выполняет эквиваленты pvscan
и vgchange -ay
, автоматически активируя все не-конфликтующие виртуальные группы по умолчанию.. В этом случае вам нужно будет только создать каталог точки монтирования, отредактировать /etc/fstab
и смонтировать том :
mkdir /olddata
<edit /etc/fstab>
mount /olddata
Какова цель vgexport
/ vgimport
тогда, спросите вы? Это для ситуации, когда вы не знаете, будет ли в новой системе ВГ с таким же именем или нет. Когда VG экспортируется, метаданные VG на диске помечаются как «пропустить меня», и поэтому VG избегает шага автоматической активации при запуске системы -,и все команды управления LVM будут отдавать предпочтение существующему не -экспортированному VG в новой системе, а не возможно -конфликтующему -именованному новому прибытию, пока системный администратор не переименует и не импортирует его. vgimport
удаляет эту метку. Больше ничего не делает.
Вышеизложенное верно для Linux LVM версии 2, которая существует с начала серии ядер 2.6. Если вы имеете дело с ядром 2.4.xx или старше, у вас может быть LVM версии 1, для которой команды vgexport
/ vgimport
могли работать по-другому (Я больше не помню подробностей о них ).