학과 서버 관리 - 운영 #365

Size: px

Start display at page:

Download "학과 서버 관리 - 운영 #365"

재은 장
6 years ago
Views:

1 학과서버관리 - 운영 #365 운영 # 354 ( 신규 ): 작업 x3650 M3 에디스크추가설치 2017/03/01 16:34 - 성제호 상태 : 완료시작시간 : 2017/03/01 우선순위 : 보통완료기한 : 담당자 : 성제호진척도 : 100% 범주 : XenServer 추정시간 : 0.00 시간 목표버전 : v1.0 설명 XenServer 로사용중인 x3650 M3 에디스크 3 개를추가하였다. 3 개모두다른곳에서사용하다, 용도를다음과같이변경하여설치하였다. 2 개는 500GB 크기의 SAS 디스크 ( 현재고장나있는 x3650 M3 서버에설치되어있던 ) 1 개는 500GB 크기의 SSD 디스크 (FreeNAS 의 Cache 로사용하기위해개인적으로구입함 ) XenServer 에서사용하기위해서는 SR 이라는단위로초기화하여야하는데, 기존에이미사용중이던디스크 2 개와구별이어려워서이기회에목록을정리하려한다. 하위일감 : 운영 # 366: XenServer 의잘못된 PBD 정보를수정 완료 이력 #1-2017/03/01 16:36 - 성제호 현재사용중인로컬디스크는다음두개의 SR 로초기화되어있다. uuid ( RO) : 3bab78ce-0638-feed-2b9b-d4c5fd name-label ( RW): Local storage name-description ( RW): host ( RO): xs1.cs.gnu.ac.kr allowed-operations (SRO): unplug; plug; PBD.create; update; PBD.d snapshot; VDI.create; VDI.destroy current-operations (SRO): VDIs (SRO): f1f4763d-68e6-4d41-8d57-263d94b38fe1; b 92ee8e541; 8fa1636d-2b7a-48f9-a13b-4981ccb16156; 2ab43af3-45aa-4bca-aeb PBDs (SRO): c77e3c1a-a170-c247-cd83-72ebf5a1904a virtual-allocation ( RO): physical-utilisation ( RO): physical-size ( RO): type ( RO): lvm content-type ( RO): user shared ( RW): false introduced-by ( RO): <not in database> is-tools-sr ( RO): false other-config (MRW): i18n-original-value-name_label: Local s sm-config (MRO): allocation: thick; use_vhd: true; devse 5e71f160ec blobs ( RO): local-cache-enabled ( RO): false tags (SRW): clustered ( RO): false uuid ( RO) : 6c425b59-c520-be17-cbcd-32e23ad89171 name-label ( RW): Local storage 2 name-description ( RW): host ( RO): xs1.cs.gnu.ac.kr allowed-operations (SRO): unplug; plug; PBD.create; update; PBD.d snapshot; VDI.create; VDI.destroy current-operations (SRO): VDIs (SRO): 56d00ab4-c79f-42db-b426-c98d4219fb46; 6 78fa3aa8; d82977df-308d-4bf3-bb8d-cca ; 32a52e65-ede d3cdeb1 PBDs (SRO): 7c00b1dd-5b0e-2f47-16f8-fbbca318949b virtual-allocation ( RO): /12/03 1/10

2 physical-utilisation ( RO): physical-size ( RO): type ( RO): lvm content-type ( RO): shared ( RW): false introduced-by ( RO): <not in database> is-tools-sr ( RO): false other-config (MRW): sm-config (MRO): allocation: thick; use_vhd: true; devse 8a6f0766a9 blobs ( RO): local-cache-enabled ( RO): false tags (SRW): clustered ( RO): false SR 은 XenServer 입장에서보면추상화된스토리지저장소이다. SR 의이면의물리장치는감춰져있는데, 이는 PBD (Physical Block Device) 라고부른다. 3bab78ce-0638-feed-2b9b-d4c5fd (Local Storage) 의 PBD [root@xs1 ~]# xe pbd-list uuid=6c425b59-c520-be17-cbcd-32e23ad89171 uuid ( RO) : c77e3c1a-a170-c247-cd83-72ebf5a1904a host ( RO) [DEPRECATED]: f899fdf6-fbad-4e28-973a-b74e706f980c host-uuid ( RO): f899fdf6-fbad-4e28-973a-b74e706f980c host-name-label ( RO): xs1.cs.gnu.ac.kr sr-uuid ( RO): 3bab78ce-0638-feed-2b9b-d4c5fd sr-name-label ( RO): Local storage device-config (MRO): device: /dev/disk/by-id/scsi b00 currently-attached ( RO): true other-config (MRW): storage_driver_domain: OpaqueRef:1d04e8 6c425b59-c520-be17-cbcd-32e23ad89171 (Local Storage 1) 의 PBD [root@xs1 ~]# xe pbd-list uuid=7c00b1dd-5b0e-2f47-16f8-fbbca318949b p uuid ( RO) : 7c00b1dd-5b0e-2f47-16f8-fbbca318949b host ( RO) [DEPRECATED]: f899fdf6-fbad-4e28-973a-b74e706f980c host-uuid ( RO): f899fdf6-fbad-4e28-973a-b74e706f980c host-name-label ( RO): xs1.cs.gnu.ac.kr sr-uuid ( RO): 6c425b59-c520-be17-cbcd-32e23ad89171 sr-name-label ( RO): Local storage 2 device-config (MRO): device: /dev/sdb currently-attached ( RO): true other-config (MRW): storage_driver_domain: OpaqueRef:1d04e8 device-config 의정보를확인하여, 해당 SR 을생성할때사용된디스크의인식자를확인할수있다. 안타깝게도, /dev/sdb 와같은형태의인식자는디스크의설치순서에따라변동될수있으므로, /dev/disk/by-i 고유번호로생성하는것이옳다. 2018/12/03 2/10

3 #2-2017/03/01 16:48 - 성제호 디스크의 id 별로설치된목록을추려보면다음과같다. [root@xs1 ~]# ls -l1 /dev/disk/by-id/scsi b00* lrwxrwxrwx 1 root root 9 2월 24 06:40 /dev/disk/by-id/scsi b003 lrwxrwxrwx 1 root root 9 2월 24 06:40 /dev/disk/by-id/scsi b003 lrwxrwxrwx 1 root root 9 2월 24 06:40 /dev/disk/by-id/scsi b003 lrwxrwxrwx 1 root root 9 2월 24 06:40 /dev/disk/by-id/scsi b004 lrwxrwxrwx 1 root root 10 2월 24 06:40 /dev/disk/by-id/scsi b004 d1 lrwxrwxrwx 1 root root 10 2월 24 06:40 /dev/disk/by-id/scsi b004 d2 lrwxrwxrwx 1 root root 10 2월 24 06:40 /dev/disk/by-id/scsi b004 d3 lrwxrwxrwx 1 root root 10 2월 24 06:40 /dev/disk/by-id/scsi b004 d4 lrwxrwxrwx 1 root root 9 3월 1 16:22 /dev/disk/by-id/scsi b004 현재이미사용중인디스크는다음의두개이다. scsi b004a372701e75955e71f160ec (/dev/sdd) scsi b003afdeb a6f0766a9 (/dev/sdb) 다음세개의디스크는새로설치한디스크이다. scsi b003afdeb a6f07149c (/dev/sda) scsi b003afdeb c77b7b700 (/dev/sdc) scsi b004a372701e75980a9ab60100 (/dev/sde) 문제는, 세개의디스크모두약 500GB 의디스크이다보니, 어느디스크가 SAS 인지 SSD 인지구별이안간다. 이디스크는 RAID 컨트롤러에의해 VD 로추상화되어있기때문에더욱그렇다. 다행히, fdisk 로확인해보니디스크하나의용량의차이가있어서이디스크가 SSD 디스크임을추측할수있었다. [root@xs1 ~]# fdisk -l /dev/sda Disk /dev/sda: GB, bytes, sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes [root@xs1 ~]# fdisk -l /dev/sdc Disk /dev/sdc: GB, bytes, sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes [root@xs1 ~]# fdisk -l /dev/sde Disk /dev/sde: GB, bytes, sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes 2018/12/03 3/10

4 #3-2017/03/01 17:05 - 성제호 참고 : How to Create a Local Storage Repository 다음과같이생성할수있다. SSD 디스크를 XenServer 의 SR 로추가한예 [root@xs1 ~]# xe sr-create content-type=user device-config:device=/de 77b7b700 host-uuid=f899fdf6-fbad-4e28-973a-b74e706f980c name-label="l 3f9baeb1-d f-50d3-6d2e9f72962a #4-2017/03/01 18:37 - 성제호 디스크중하나가다음의오류를일으키며 SR 로추가되지않았다. [root@xs1 /]# xe sr-create content-type=user device-config:device=/dev/ 0100 host-uuid=f899fdf6-fbad-4e28-973a-b74e706f980c name-label="local The SR operation cannot be performed because a device underlying the SR 이미해당디스크가 SR 로사용되고있다는에러였다. SR 목록과 PBD 목록을모두뽑아서해당디스크가사용되고있는지확인했으나, 실제로사용되지않고있었다. SR 을추가시키는과정에서어떤오류가발생하는지확인하고싶어서, /var/log/smlog 파일을확인해보았다. /var/log/smlog DummyRef: 700b3f1b-ef71-8b6a-31f4-53ce3111b2e2 SR.create', 'args': [' eaca-9a8f8944c3a6', 'session_ref': 'OpaqueRef:80f8232d d53-9ae9 /disk/by-id/scsi b004a372701e75980a9ab60100', 'SRmaster': 'tru Mar 1 17:25:03 xs1 SM: [24449] lock: opening lock file /var/lock/sm/ sr Mar 1 17:25:03 xs1 SM: [24449] LVMCache created for VG_XenStorage-16 e Mar 1 17:25:03 xs1 SM: [24449] ['/sbin/vgs', 'VG_XenStorage-16005b20 Mar 1 17:25:03 xs1 SM: [24449] FAILED in util.pread: (rc 5) stdout: enstorage-16005b20-96d3-c02b-494f-f47d969370be" not found Mar 1 17:25:03 xs1 SM: [24449] Cannot process volume group VG_XenS 47d969370be Mar 1 17:25:03 xs1 SM: [24449] ' Mar 1 17:25:03 xs1 SM: [24449] LVMCache: will initialize now Mar 1 17:25:03 xs1 SM: [24449] LVMCache: refreshing Mar 1 17:25:03 xs1 SM: [24449] ['/sbin/lvs', '--noheadings', '--unit 16005b20-96d3-c02b-494f-f47d969370be'] Mar 1 17:25:04 xs1 SM: [24449] FAILED in util.pread: (rc 5) stdout: enstorage-16005b20-96d3-c02b-494f-f47d969370be" not found Mar 1 17:25:04 xs1 SM: [24449] Cannot process volume group VG_XenS 47d969370be Mar 1 17:25:04 xs1 SM: [24449] ' Mar 1 17:25:04 xs1 SM: [24449] lock: acquired /var/lock/sm/16005b20- Mar 1 17:25:04 xs1 SM: [24449] sr_create {'sr_uuid': '16005b20-96d3- f:6d900c76-fe83-76dd-a3b8-ccc1ef8c7997'} Mar 1 17:25:04 xs1 SM: [24449] LVHDSR.create for 16005b20-96d3-c02b- Mar 1 17:25:04 xs1 SM: [24449] ['/sbin/vgs', 'VG_XenStorage-16005b /12/03 4/10

5 The SR device is currently in use [opterr=device /dev/disk/by-id/scsi device is currently in use [opterr=device /dev/disk/by-id/scsi Mar 1 17:25:04 xs1 SM: [24449] FAILED in util.pread: (rc 5) stdout: enstorage-16005b20-96d3-c02b-494f-f47d969370be" not found Mar 1 17:25:04 xs1 SM: [24449] Cannot process volume group VG_XenS 47d969370be Mar 1 17:25:04 xs1 SM: [24449] ' Mar 1 17:25:04 xs1 SM: [24449] ['sginfo', '-s', '/dev/sde'] Mar 1 17:25:04 xs1 SM: [24449] pread SUCCESS Mar 1 17:25:04 xs1 SM: [24449] ['/usr/lib/udev/scsi_id', '-g', '--de Mar 1 17:25:04 xs1 SM: [24449] pread SUCCESS Mar 1 17:25:04 xs1 SM: [24449] Raising exception [16, The SR device e /dev/disk/by-id/scsi b004a372701e75980a9ab60100 in use, plea nce of this device]] Mar 1 17:25:04 xs1 SM: [24449] lock: released /var/lock/sm/16005b20- Mar 1 17:25:04 xs1 SM: [24449] ***** generic exception: sr_create: E use, please check your existing SRs for an instance of this device] Mar 1 17:25:04 xs1 SM: [24449] return self._run_locked(sr) Mar 1 17:25:04 xs1 SM: [24449] rv = self._run(sr, target) Mar 1 17:25:04 xs1 SM: [24449] return sr.create(self.params['sr_ Mar 1 17:25:04 xs1 SM: [24449] File "/opt/xensource/sm/lvmsr", lin Mar 1 17:25:04 xs1 SM: [24449] lvutil.createvg(self.root, self.v Mar 1 17:25:04 xs1 SM: [24449] File "/opt/xensource/sm/lvutil.py", Mar 1 17:25:04 xs1 SM: [24449] + 'SRs for an instance of this de Mar 1 17:25:04 xs1 SM: [24449] File "/opt/xensource/sm/xs_errors.p Mar 1 17:25:04 xs1 SM: [24449] raise SR.SROSError(errorcode, err Mar 1 17:25:04 xs1 SM: [24449] Mar 1 17:25:04 xs1 SM: [24449] ***** Local VHD on LVM: EXCEPTION <cl ase check your existing SRs for an instance of this device] Mar 1 17:25:04 xs1 SM: [24449] ret = cmd.run(sr) Mar 1 17:25:04 xs1 SM: [24449] return self._run_locked(sr) Mar 1 17:25:04 xs1 SM: [24449] rv = self._run(sr, target) Mar 1 17:25:04 xs1 SM: [24449] return sr.create(self.params['sr_ Mar 1 17:25:04 xs1 SM: [24449] File "/opt/xensource/sm/lvmsr", lin Mar 1 17:25:04 xs1 SM: [24449] lvutil.createvg(self.root, self.v Mar 1 17:25:04 xs1 SM: [24449] File "/opt/xensource/sm/lvutil.py", Mar 1 17:25:04 xs1 SM: [24449] + 'SRs for an instance of this de Mar 1 17:25:04 xs1 SM: [24449] File "/opt/xensource/sm/xs_errors.p Mar 1 17:25:04 xs1 SM: [24449] raise SR.SROSError(errorcode, err Mar 1 17:25:04 xs1 SM: [24449] Mar 1 17:25:04 xs1 SM: [24449] lock: closed /var/lock/sm/16005b20-96 정상적으로생성되는 SR 로그와비교해보면, 중간에이미 SR 이사용된다는예외가발생함을볼수있다. 이것이처음에는 XenServer 의메타데이터상의손상이라고생각했으나, 디스크상에남아있는잔재로인한오류일것으로생각되었 실제로, 로그상의 backtrace 를확인해보면, /opt/xensource/sm/lvutil.py 635번째줄에서오류가발생했다의 backtrace 의 /opt/xensource/sm/xs_errors.py 는실제오류가발생한함수이니, 그직전의 lvu 한다. /opt/xensource/sm/lvutil.py 의 616~636 번째줄 defcreatevg (root, vgname, 'thick sr_alloc= '): systemroot = util.getrootdev() rootdev = root.split( ',')[0] # Create PVs for each device fordev inroot.split( ','): ifdev in[systemroot, '%s1' % systemroot, '%s2' % systemroot]: raise xs_errors.xenerror( 'Rootdev ', \ opterr=( 'Device %s contains core ' system \ files, + 'please use another ') % dev) device ifnotos.path.exists(dev): raise xs_errors.xenerror( 'InvalidDev ', \ opterr=( 'Device %s does not ') % exist dev) 2018/12/03 5/10

6 try : f = os.open( "%s" % dev, os.o_rdwr os.o_excl) except : raise xs_errors.xenerror( 'SRInUse ', \ opterr=( 'Device %s in use, please check ' \ your existing + 'SRs for an instance of ') % this dev) device os.close(f) 이함수는, 해당디스크에서 PV 를생성하는항목이다. 여기서 f = os.open("%s" % dev, os.o_rdwr 항목을실행하는 도중 os.o_excl) 오류가발생해서 SRInUse 예외가발동된것이다. dev 는 /dev/disk/by-id/scsi b004a372701e75980a9ab60100 로추정된다. 이것을실제시스템에서수행해봤더니다음과같은오류가발생했다. >>> import os >>> os.open("/dev/disk/by-id/scsi b004a372701e75980a9ab60100", o Traceback (most recent call last): File "<stdin>", line 1, in <module> OSError: [Errno 16] Device or resource busy: '/dev/disk/by-id/scsi-3600 장치를열수없으며, 해당에러번호는 16 번이고이는 SMlog 상에서도나타나있다. 어째서해당장치가바쁜 ( 사용중 ) 인것인가? #5-2017/03/01 18:59 - 성제호 사실이논의를이어나가기위해서는, 일종의논리의연결이형성되어야한다. 즉, 이런오류가났는데이런이유때문에발생한것이다. 라는논리의연결이문제까지이어져야한다. 안타깝게도, 중간의연결고리가끊어졌다. 즉, 답은알지만논리의연결이중간에마치손실되어마법처럼이어져있다. 이문제의정답부터말하자면, 새로설치된디스크에이미 LVM 이구성되어있던것이문제였다. 이것이이미 LVM 에의해 scan 되어 import 되어있었기때문에, 장치는이미사용중이었고쓰기모드로읽을수없었 /dev/disk/by-id/scsi b004a372701e75980a9ab > /dev/sde [root@xs1 /]# pvscan PV /dev/sde VG VG_XenStorage-6c425b59-c520-be17-cbcd-32e23ad8917 GiB free]... 생략... [root@xs1 /]# pvdisplay /dev/disk/by-id/scsi b004a372701e Physical volume /12/03 6/10

7 PV Name /dev/sde VG Name VG_XenStorage-6c425b59-c520-be17-cbcd-32e23ad PV Size GiB / not usable MiB Allocatable yes PE Size 4.00 MiB Total PE Free PE Allocated PE PV UUID V9NPnN-ljFB-1TCL-dm8o-0c7n-aDET-kLViHS 이를완전히 destroy 시킨후, 다시 SR 을생성하면될것이다. 그러나, 다음과같은에러가발생하였다. [root@xs1 /]# pvremove -vf /dev/disk/by-id/scsi b004a372701e7598 pvremove -vf /dev/disk/by-id/scsi b004a372701e75980a9ab60100: ata_read_only is set. 이는 lvm.conf 설정파일에다음과같이제약되어있기때문이었다. /etc/lvm/lvm.conf # Configuration option global/metadata_read_only. # No operations that change on-disk metadata are permitted. # Additionally, read-only commands that encounter metadata in # repair will still be allowed to proceed exactly as if the r # been performed (except for the unchanged vg_seqno). Inappro # use could mess up your system, so seek advice first! metadata_read_only = 1 굳이 XenServer 의설정을강제로바꾸고싶지않았기때문에, 다른방법을찾아야했다. 커뮤니티에서권장하는방법은다음과같았다. LVM 관련명령을수행할때, metadata_read_only 설정을일시적으로무력화하는방법 sr-introduce 명령으로, 기존의 SR 을현재의 XenServer 로 introduce 하는방법 ( 참고 Recover a LVM config after ) accidentarl 'sr-create..' SR 을잘다루는것은 XenServer 운영에매우중요하므로, sr-introduce 를연습해보기로한다. 2018/12/03 7/10

8 #6-2017/03/01 19:23 - 성제호 참고 : How to Introduce a Local Storage Repository in XenServer XenServer 에서는 SR 이라는단위로저장소를바라본다. 추상화된 SR 을대상으로블록을다루는데, SR 의이면에는실제물리장치를정의한 PBD 가존재한다. XenServer 들은, 그리고 VM 의디스크들은모두 SR 을인식한다. 따라서, 이를인식하는수단인 SR 의 UUID 가중요해진다. 그래서 SR 을 introduce 하는과정에는기존에사용하던 SR 의 UUID 를그대로보존하는것이중요하다. 다음과같이 introduce 가이루어진다. 1.sr introduce 명령을이용해고정된 uuid 와속성을 XenServer 에등록함 2.pbd create 하여, introduce 한 SR 의 UUID 에연결한다 3.pbd plug 하여, 실제장치에 PBD 를연결한다 기존에사용하던디스크를 XenServer 에불러오는상황인데, VG 이름에기존에사용하던 SR 의 UUID 가이미기록되즉, 이전의 SR 에서는 6c425b59-c520-be17-cbcd-32e23ad89171 라는 UUID 를사용했음을알수 [root@xs1 ~]# pvscan PV /dev/sde VG VG_XenStorage-6c425b59-c520-be17-cbcd-32e23ad89171 free] sr-introduce 로 6c425b59-c520-be17-cbcd-32e23ad89171 라는 UUID 의 SR 을생성 [root@xs1 ~]# xe sr-introduce uuid=6c425b59-c520-be17-cbcd-32e23ad891 4" content-type=user An SR with that uuid already exists. uuid: 6c425b59-c520-be17-cbcd-32e23ad89171 이런, 이미 6c425b59-c520-be17-cbcd-32e23ad89171 가사용중이다. UUID 가겹칠확률은거의불찾아보니, 기존에 SR 로사용중인디스크의 UUID 로확인되었다. 아마도이전에 Mirror 로사용되던디스크를다시장착한게아닌가생각된다. Mirror 구성된디스크는서로완전히동일하기때문이다절대로. 겹칠따라서수없는 UUID 가겹치게된것같다. SR 을 introduce 하려면, VG 의이름부터바꾸는작업부터해야할것같다. 새로운 UUID 는 SMlog 에기록되어있던실패한 UUID 인 16005b20-96d3-c02b-494f-f47d96937 기존디스크의 VG 이름을새로운 UUID 를포함한이름으로변경이때 metadata_read_only 옵션을 0 으로해제함 [root@xs1 ~]# sudo vgrename VG_XenStorage-6c425b59-c520-be17-cbcd-32e d3-c02b-494f-f47d969370be --config global{metadata_read_only=0} Volume group "VG_XenStorage-6c425b59-c520-be17-cbcd-32e23ad89171" s e-16005b20-96d3-c02b-494f-f47d969370be" 변경된 VG 를활성화 [root@xs1 ~]# vgchange -ay VG_XenStorage-16005b20-96d3-c02b-494f-f47d only=0} 6 logical volume(s) in volume group "VG_XenStorage-16005b20-96d3-c0 새로운 UUID 를기준으로 sr-introduce 함 [root@xs1 ~]# xe sr-introduce uuid=16005b20-96d3-c02b-494f-f47d " content-type=user 16005b20-96d3-c02b-494f-f47d969370be 새로생성한 SR 에 PBD 를생성함 [root@xs1 ~]# xe pbd-create sr-uuid=16005b20-96d3-c02b-494f-f47d /12/03 8/10

9 csi b004a372701e75980a9ab60100 host-uuid=f899fdf6-fbad-4e fb161a-76a6-06fa-c08e-899f3f88e925 pbd-plug 로생성한 PBD 를활성화 ~]# xe pbd-plug uuid=84fb161a-76a6-06fa-c08e-899f3f88e925 #7-2017/03/01 19:58 - 성제호 아주심각한문제가생겼다 전제로생각했던, PBD device-config 객체의 (MRO): 항목은 device: 실제가아니었다 /dev/sdb. 즉, 내가 /dev/sdb 가해당 PBD 의연결이라고생각했지만, 실제로는 /dev/sde 에연결되어있었다. Mirror 디스크라서기존디스크와의내용이공교롭게겹친것이아니라, 실제로사용중인디스크였던것이다. 이작업은다행히도중에이상한증상을보여알수있었다. 새로생성한 SR 에서 rescan 이불가능했고기존디스크의 SR 에서디스크생성이불가능했다. 따라서 VG 이름을다시원복하여, 기존 SR 에서가상디스크생성이동작함을확인했다. 그러나새로생성한 SR 은 PBD 를 unplug 하는것은불가능했다. 이대로 XenServer 를재기동한다면문제가된신규 SR 을해제하는과정에서 Hang 이걸려버릴것이다. 그러나현재는재기동하지않으면새로생성한 PBD 와 SR 을삭제하는것이불가능하다. #8-2017/03/01 20:04 - 성제호 다행히큰문제없이새로생성했던 PBD 와 SR 을제거할수있었다. 재부팅은필요없게되었다. [root@xs1 log]# xe pbd-unplug uuid=84fb161a-76a6-06fa-c08e-899f3f88e925 [root@xs1 log]# xe pbd-destroy uuid=84fb161a-76a6-06fa-c08e-899f3f88e92 [root@xs1 log]# xe sr-destroy uuid=16005b20-96d3-c02b-494f-f47d969370be The SR has no attached PBDs sr: 16005b20-96d3-c02b-494f-f47d969370be (Local storage 4) [root@xs1 log]# xe sr-forget uuid=16005b20-96d3-c02b-494f-f47d969370be 2018/12/03 9/10

10 Powered by TCPDF ( #9-2017/03/01 20:33 - 성제호 성제호의덧글 : 아주심각한문제가생겼다 전제로생각했던, PBD device-config 객체의 (MRO): 항목은 device: 실제가아니었다 /dev/sdb. 즉, 내가 /dev/sdb 가해당 PBD 의연결이라고생각했지만, 실제로는 /dev/sde 에연결되어있었다. Mirror 디스크라서기존디스크와의내용이공교롭게겹친것이아니라, 실제로사용중인디스크였던것이다. 이문제를해결하기위해 #366일감을생성하여처리하였다. 현재는정상적으로교정되었다. # /03/01 20:36 - 성제호마지막디스크를정상적으로추가하였다. [root@xs1 ~]# xe sr-create content-type=user device-config:device=/dev/ 66a9 host-uuid=f899fdf6-fbad-4e28-973a-b74e706f980c name-label="local 0eab3a11-d5a5-5b7f-3090-d7b1916b8105 # /03/01 20:40 - 성제호 - 파일에 pbd-list_ txt 이 ( 가 ) 추가되었습니다. - 파일에 sr-list_ txt 이 ( 가 ) 추가되었습니다. 현재의 SR 과 PBD 목록을정리하였다. # /03/01 20:40 - 성제호 - 목표버전을 ( 를 ) 시작에서 v1.0( 으 ) 로변경되었습니다. - 담당자을 ( 를 ) 성제호 ( 으 ) 로지정되었습니다. - 상태을 ( 를 ) 신규에서완료 ( 으 ) 로변경되었습니다. - 범주을 ( 를 ) XenServer( 으 ) 로지정되었습니다. 파일 pbd-list_ txt 2.89 KB2017/03/01 성제호 sr-list_ txt 5.75 KB2017/03/01 성제호 2018/12/03 10/10

휠세미나3 ver0.4

휠세미나3 ver0.4 andromeda@sparcs:/$ ls -al dev/sda* brw-rw---- 1 root disk 8, 0 2014-06-09 18:43 dev/sda brw-rw---- 1 root disk 8, 1 2014-06-09 18:43 dev/sda1 brw-rw---- 1 root disk 8, 2 2014-06-09 18:43 dev/sda2 andromeda@sparcs:/$