Burrito is a security-hardened OpenStack on Kubernetes Platform.
- GitHub Release: https://github.com/iorchard/burrito/releases/tag/2.1.3
- Documentation: https://burrito.readthedocs.io/en/2.1.3/
Notable Changes
- Fix: kubernetes certificate renewal script (k8s-certs-renew.sh) (issue #254)
- Enhancement: Upgrade NetApp Trident to 24.06.1. (issue #255)
- Feature: Support Dell/EMC PowerStore storage backend. (issue #232)
- Enhancement: Use PVC for glance store if PowerFlex is the storage backend (issue #246)
There is a regression bug in kubernetes certificate auto-renew script. The affected versions are from Burrito 1.2.4 to 2.1.2.
For users who are using those versions, follow the errata document at Errata.
Burrito 1.2.3 and earler does not have this bug and the latest version 2.1.3 has already this bug patched.
]]>Burrito is a security-hardened OpenStack on Kubernetes Platform.
- GitHub Release: https://github.com/iorchard/burrito/releases/tag/2.1.2
- Documentation: https://burrito.readthedocs.io/en/2.1.2/
Notable Changes
- Upgrade: powerflex SDC and csi driver upgrade to support kubernetes v1.30.x. (issue #227)
- Fix: cannot open novnc console. (issue #231)
- Fix: podman is removed when ceph nodes are in kubernetes node group (issue #234)
- Fix: nova-storage-init job is pulling an image from docker.io in offline environment. (issue #235)
This is the demo of Provisioning K8S Cluster on PBOS platform using Pulumi.
PBOS is an ansible playbook suite to install OpenStack on Baremetal. PBOS stands for Pure Baremetal OpenStack.
Pulumi is an IaC tool.
Demo
PBOS is an ansible playbook suite to install OpenStack on Baremetal. PBOS stands for Pure Baremetal OpenStack.
There are 1 playbook and 16 roles in PBOS.
PBOS has 3 groups.
- pbos-infra: HA and infrastructure related components
- pbos-storage: Backend Storage (It supports Ceph and LVM/iSCSI)
- openstack: OpenStack components
Demo
OkiDoki is a project to achieve VM High Availability for OpenStack platform.
It uses Masakari, Corosync, and Pacemaker.
Masakari: provides Instances High Availability Service for OpenStack
- recover KVM-based Virtual Machine(VM)s from failure events
- an API service to manage and control the automated rescue mechanism
Cluster stack: Corosync, Pacemaker, Pacemaker-remote for HA
- Corosync: cluster engine
- Pacemaker: resource manager
- Pacemaker-remote: lightweight resource manager for scalability. (corosync/pacemaker cluster has a limit of 16 nodes.)
OkiDoki Components
Controller nodes
- corosync/pacemaker
- masakari-api: Get notifications of instance/host failures from monitor
- masakari-engine: Process recovery workflow for instance/host failure
Compute nodes
- pacemaker-remote
- masakari-instancemonitor
- masakari-hostmonitor
masakari-processmonitor is not used by OkiDoki because openstack components are running as pods on kubernetes system. Kubernetes itself can handle nova-compute service failure.
Demo
Sparring is a test robot suite for OpenStack platform.
There are 3 robots for now.
- funcbot: a functional test robot for openstack
- perfbot: a performance test robot for openstack
- cdbot: a continuous deployment test robot for openstack API services
funcbot
Use robotframework and gabbi library for functional tests
There are 5 test suites
- identity: Keystone API test
- network: Neutron API test
- image: Glance API test
- volume: Cinder API test
- compute: Nova API test
There are 3 areas - Keyword, Code, Manifest
- Keyword: This area is for tester. Just put keywords from Code area.
- Code: This area is for programmer. Program logic of keywords are here.
- Manifest: This area is for programmer. OpenStack API calls are here.
Keyword example: Given-When-Then example:
Start the server
[Tags] compute critical
Given Compute service is available
When Start the server
Then Check if the server is active
Code example: Use robotframework libraries:
Check if the server is active
Wait Until Keyword Succeeds 2m 3s
... check server is active url=${COMPUTE_SERVICE}
Manifest example: API manifests are defined in yaml format using gabbi:
- name: check server is active
GET: /servers/$ENVIRON['TEST_SERVER_ID']
status: 200
response_json_paths:
$.server.status: ACTIVE
How to use funcbot
Get the sample openstack_settings.robot file to /tmp/ and Edit settings above “Do not touch below!!!” line.:
docker run --rm --name sparring jijisa/sparring \
--show-os-settings > /tmp/settings.robot
To run all test suites in funcbot (This is default.):
docker run --rm --tty --network=host --name sparring \
-v /etc/hosts:/etc/hosts:ro -v /tmp/output:/tmp/output \
-v /tmp/settings.robot:/sparring/resources/openstack_settings.robot:ro \
jijisa/sparring
To run specific test suites(e.g. network and image) in funcbot:
docker run --rm --tty --network=host --name sparring \
-v /etc/hosts:/etc/hosts:ro -v /tmp/output:/tmp/output \
-v /tmp/settings.robot:/sparring/resources/openstack_settings.robot:ro \
jijisa/sparring --run-funcbot network image
To run all test cases except evacuation test in funcbot (funcbot forces compute service down to evacuate test VM instance so the option(-e) excluding evacuation test is useful when you run Sparring funcbot in production environment.):
docker run --rm --tty --network=host --name sparring \
-v /etc/hosts:/etc/hosts:ro -v /tmp/output:/tmp/output \
-v /tmp/settings.robot:/sparring/resources/openstack_settings.robot:ro \
jijisa/sparring --run-funcbot -e
Deliverables
- Sparring source: https://github.com/iorchard/sparring.git
- Sparring images: https://hub.docker.com/r/jijisa/sparring (docker pull jijisa/sparring)
Demo
쿠버네티스 환경에서 특정 컨테이너의 인터페이스를 모니터할 일이 생겼는데,
해당 컨테이너 인터페이스의 pair가 어떤건지 식별하는 방법을 모르겠어서 이곳에 기록하고 공유한다.
먼저 찾으려는 pod의 pause 컨테이너ID를 찾는다.:
$ sudo docker ps |grep proxy-nginx
89a1d0a081f3 5a3221f0137b "nginx -g xy-nginx-576d4fd9cd-4gprn_fd790dd7-3c0b-11ea-be0d-e4434b6e257c_0
221c4add4238 google_containers/pause-amd64:3.1 "/pause" -nginx-576d4fd9cd-4gprn_fd790dd7-3c0b-11ea-be0d-e4434b6e257c_0
- 두 번째 컨테이너인 221c4add4238가 네트워크 네임스페이스를 공유하는 pause 컨테이너이다.
pause 컨테이너의 ID를 가지고 pid를 찾는다.:
$ sudo docker inspect --format '{{ .State.Pid }}' 221c4add4238
68855
찾은 pid를 가지고 해당 pid의 네트워크 네임스페이스 안에서 인터페이스 인덱스를 식별한다.:
$ sudo nsenter -t 68855 -n ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
3: eth0@if232: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether 36:e4:45:56:18:99 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 172.18.206.132/32 scope global eth0
valid_lft forever preferred_lft forever
- 컨테이너의 인터페이스인 eth0과 pair 맺은 인터페이스 인덱스는 232번 이다.
이제 호스트에서 인덱스 232 번 인터페이스를 찾는다.:
$ ip a |grep 232
232: cali29544dc48cd@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
- cali29544dc48cd인터페이스임을 알 수 있다.
reference
]]>[개요]
GitLab 사용에 기본이 될수 있는 프로젝트 생성부터, git clone, push, pull 에 대한 내용을 간략하게 보여줍니다.
아래 환경은 웹페이지 + 리눅스 bashShell 기반으로 작성합니다.
그리고 git 미설치 상태이시면 “apt install git” 으로 git 패키지를 설치 합니다.
1.project 초대
2.git config
3.git clone, add, commit, push
4.기존, 새로운 폴더 push
5.git pull
1.project 초대
프로젝트 선택후 아래의 이미지를 따라 갑니다.
Select members to invite, permission, 등을 선택후 Add to project 합니다.
2.git config
이름, E-mail 등록:
git config --global user.name "orchard"
git config --global user.email "[email protected]"
config 확인:
# git config --list
user.name=orchard
user.email=support@iorchard.co.kr
3.git clone, add, commit, push
git clone:
# git clone http://192.168.0.161/Min/testproject.git
Cloning into 'testproject'...
warning: You appear to have cloned an empty repository.
clone 확인:
# ls
testproject
폴더만 생성된 상태이고 경로 안에는 아무것도 없는 상태 입니다.
빈 깡통의 폴더로 접근하여 파일 생성, commit, push 합니다.:
# cd testproject
touch index.html
아래는 리스트로 파일 생성 확인:
# ls
index.html
위의 생성된 파일로 commit 전에 git add 합니다.:
# git add index.html
git add ‘파일명’ 이 아닌
“git add .” 으로 생성된 모든 것을 git add 가능
git commit 시도 ‘-m’ 옵션으로 메세지를 남겨 주어야 한다.:
# git commit -m "messa..."
[master (root-commit) 26b8fde] messa...
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 index.html
commit 이후 마지막 단계 git push
‘git push -u origin 브랜치명’ - 현재 브랜치명은 master로 되어 있음.
브랜치는 사용자 기호에 따라 추가 가능.
git push -u
Enumerating objects: 3, done.
Counting objects: 100% (3/3), done.
Writing objects: 100% (3/3), 207 bytes | 207.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To http://192.168.0.161/Min/testproject.git
...
push 이후 웹페이지 확인
위 이미지로 index가 push 된걸 알수 있다.
4.기존, 새로운 폴더 push
기존 자신이 가지고 있던 소스를 push 하기 위해 사용될것으로 보입니다.
Tip. GitLab의 새로운 프로젝트 생성후 프로젝트 경로의 공간이 비워 있는상태에서 push 하는 추천.
해당 폴더로 접근후 git init 해준다.:
# cd forder
# git init
Initialized empty Git repository in /Users/sunmin/Desktop/gittest/forder/.git/
remote 저장소 등록 후 push 까지:
# git remote add origin http://192.168.0.161/Min/testproject2.git
# git add .
# git commit -m "forder"
On branch master
nothing to commit, working tree clean
# git push -u origin master
Enumerating objects: 3, done.
Counting objects: 100% (3/3), done.
Writing objects: 100% (3/3), 203 bytes | 203.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To http://192.168.0.161/Min/testproject2.git
* [new branch] master -> master
Branch 'master' set up to track remote branch 'master' from 'origin'.
5.git pull
다른 누군가가 추가 파일을 업로드해 둔게 있다면 pull 로 당겨 온다.:
# git pull
remote: Enumerating objects: 4, done.
remote: Counting objects: 100% (4/4), done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
From http://192.168.0.161/Min/testproject
26b8fde..1eeef43 master -> origin/master
Updating 26b8fde..1eeef43
Fast-forward
test1 | 1 +
1 file changed, 1 insertion(+)
create mode 100644 test1
‘git pull origin 브랜치명’ 으로 특정 브랜치의 pull 도 가능 하다.
[개요]
브라운스톤 사무실 이사후 UXEN3 테스트 서버 구축 완료. ( AOE 이슈 문제 제외하고 완료)
서초 UXEN3 기능시험서를 참고 하여 테스트 한다.
기능시험 테스트환경이 알맞은지는 모르겠지만, 시작해 본다. ( 알맞은 환경이 아니면 기능시험에 맞는 환경을 구성하고 다시 시험 할 것임)
기능시험서에 하드웨어 구성 및 패키지 버젼 확인후 vm create 부터 시작.
dwade VM 에서 시험
iscsi volume의 gvm을 사용
storlink 는 local 사용
Tip]
/opt/uxen3/var/log/uxenapi.log 를 확인하면서 실제 어떤 명령이 떨어지는지 확인해 본다.
아래의 모든 내용을 실행결과 uxencli 관련명령어로 수행 되는 실제 명령어 들은
qemu-img covert
qemu-img create
DB 정보 변경
위의 3가지 위주로 이루어 진다.
command line 이후 comment가 없는 부분은 기능 정상임.
VM 관련기능.
1.VM Create:
# uxencli vm-add Uxen3TestVM 1b14c1cd-a374-406c-b1e4-5be320c1cad6 1 1 1024 2048 "Uxen3 Test VM" xenbr0 xenbr1
Success
2.VM Start:
# uxencli vm-start ad9275d2-92df-40be-9fc2-de10457d3c1e
Success
3.VM Copy - Online:
# local storlink VM을 local storlink로 Online으로 copy
# uxencli vm-copy ad9275d2-92df-40be-9fc2-de10457d3c1e Uxen3TestVMcopy 1
Success
Online으로 copy 후 VM 구동시 구동은 되지만 아래의 에러가 나타남.:
xen:manage: setup_shutdown_watcher: Error -13 writing feature-poweroff
3.VM Copy - Offline:
# uxencli vm-copy ad9275d2-92df-40be-9fc2-de10457d3c1e Uxen3TestVMcopy2 1
Success
Online copy와 동일한 에러가 있다.:
xen:manage: setup_shutdown_watcher: Error -13 writing feature-poweroff
새로 생성하는 VM에서도 똑같은 에러가 보이는것으로 보아 큰 문제점은 아닌것으로 보인다.
4.VM Delete:
# uxencli vm-del 496b3e6a-6b38-48c6-b9cb-204336cf1393
Success
Delete 전:
ls
292e588f-549e-4aa1-a4e8-9f21b7efed0a 35e8eea5-19d6-4023-9c42-1025b32819d6
33f5ca20-45ac-4159-8480-294654691b10 4f6c5c69-2bb4-4ec4-a856-2b69b865343d
Delete 후:
ls
292e588f-549e-4aa1-a4e8-9f21b7efed0a 35e8eea5-19d6-4023-9c42-1025b32819d6 4f6c5c69-2bb4-4ec4-a856-2b69b865343d
5.VM Disk Create - Online:
# uxencli vm-disk-add ad9275d2-92df-40be-9fc2-de10457d3c1e 20000 1 "disk add test1"
Success
# uxencli vm-disk-list ad9275d2-92df-40be-9fc2-de10457d3c1e
DISK_UUID STORLINK SIZE FORMAT ORDER
4f6c5c69-2bb4-4ec4-a856-2b69b865343d 1 30720 qcow2 1
2d010062-8fc5-44c4-9d15-1af96ff96595 1 20000 qcow2 2
5.VM Disk Create - Offline:
# uxencli vm-disk-add ad9275d2-92df-40be-9fc2-de10457d3c1e 19000 1 "disk add test2"
Success
# uxencli vm-disk-list ad9275d2-92df-40be-9fc2-de10457d3c1e
DISK_UUID STORLINK SIZE FORMAT ORDER
4f6c5c69-2bb4-4ec4-a856-2b69b865343d 1 30720 qcow2 1
2d010062-8fc5-44c4-9d15-1af96ff96595 1 20000 qcow2 2
3744167b-5104-4217-aeb6-c6c7a19247f8 1 19000 qcow2 3
6.VM Disk Delete - Online:
# uxencli vm-disk-del ad9275d2-92df-40be-9fc2-de10457d3c1e 3744167b-5104-4217-aeb6-c6c7a19247f8
Failure (Bad Request) : {"message":"The VM should not be running.","result":102}
6.VM Disk Delete - Offline:
# uxencli vm-disk-del ad9275d2-92df-40be-9fc2-de10457d3c1e 3744167b-5104-4217-aeb6-c6c7a19247f8
Success
# uxencli vm-disk-list ad9275d2-92df-40be-9fc2-de10457d3c1e
DISK_UUID STORLINK SIZE FORMAT ORDER
4f6c5c69-2bb4-4ec4-a856-2b69b865343d 1 30720 qcow2 1
2d010062-8fc5-44c4-9d15-1af96ff96595 1 20000 qcow2 2
7.VM Disk List:
# uxencli vm-disk-list ad9275d2-92df-40be-9fc2-de10457d3c1e
DISK_UUID STORLINK SIZE FORMAT ORDER
4f6c5c69-2bb4-4ec4-a856-2b69b865343d 1 30720 qcow2 1
2d010062-8fc5-44c4-9d15-1af96ff96595 1 20000 qcow2 2
8.VM information:
# uxencli vm-info ad9275d2-92df-40be-9fc2-de10457d3c1e
UUID : ad9275d2-92df-40be-9fc2-de10457d3c1e
Name : Uxen3TestVM
Cpu : 1
Maxmem : 2048
Memory : 1024
OS : DEBIAN
OS Arch : X64
State : RUNNING
GVM : 1b14c1cd-a374-406c-b1e4-5be320c1cad6
Created : 2019-06-24T07:36:57.292553Z
Recent Booted : 2019-06-25T06:42:18.874897Z
Networks : [ifname] [mac]
xenbr1 00:16:3E:BD:ED:6B
xenbr0 00:16:3E:63:97:8E
VNC Port : 5902
VNC Password : 9zh04lvst5x8
9.VM List:
# uxencli vm-list
UUID NAME vCPU MEM STATUS PM
85c019e1-6eac-4cd1-b732-0a331632dd56 a_g_disk2_t 1 1024 SHUTDOWN -
40edeb71-dc4b-4b77-9156-856f64271419 bondvm 1 1024 SHUTDOWN -
ad9275d2-92df-40be-9fc2-de10457d3c1e Uxen3TestVM 1 1024 RUNNING E0A697BE-C47E-DD11-98FB-0023540D61DA
af09497e-51be-4b60-bbf6-e36f38e32ab8 gitlab_t 2 2048 RUNNING A064D172-E07E-DD11-91FE-0023541104C2
3fcf68de-f08f-4de7-952c-471795ba6bdf a_w_i_t 1 1024 SHUTDOWN -
6846366b-4430-4139-84cd-7bc05e968d21 iscsivm 1 1024 RUNNING E0A697BE-C47E-DD11-98FB-0023540D61DA
31eaec7b-b031-4226-821e-7c892aaebdb7 jennie_nfs_vm 1 1024 RUNNING A064D172-E07E-DD11-91FE-0023541104C2
deaf14fc-f7d6-43d8-8712-218afb8037db jennie_aoe_vm 1 1024 RUNNING A064D172-E07E-DD11-91FE-0023541104C2
10.VM Shutdown:
# uxencli vm-shutdown ad9275d2-92df-40be-9fc2-de10457d3c1e
Success
11.VM Poweroff:
# uxencli vm-poweroff ad9275d2-92df-40be-9fc2-de10457d3c1e
Success
12.VM Reboot:
# uxencli vm-reboot ad9275d2-92df-40be-9fc2-de10457d3c1e
Success
13.VM State:
# uxencli vm-stat ad9275d2-92df-40be-9fc2-de10457d3c1e
UUID : ad9275d2-92df-40be-9fc2-de10457d3c1e
Name : Uxen3TestVM
CPU cores : 1
CPU util. : 0.1 %
Memory : 1024
Networks : [ifname] [rx_sum] [tx_sum]
total 1862 81540
xenbr1 0 28783
xenbr0 1862 52757
14.VM Suspend:
# uxencli vm-suspend ad9275d2-92df-40be-9fc2-de10457d3c1e
Success
# uxencli vm-list
UUID NAME vCPU MEM STATUS PM
ad9275d2-92df-40be-9fc2-de10457d3c1e Uxen3TestVM 1 1024 SUSPEND E0A697BE-C47E-DD11-98FB-0023540D61DA
VM이 중지 되며, VNC 로는 접속이 가능 하다. 단 멈춰 있다.
ssh 는 접속이 가능 할까?
접속 불가… 중지된 VM에 PING 테스트도 불가능.
15.VM Resume:
# uxencli vm-resume ad9275d2-92df-40be-9fc2-de10457d3c1e
Success
16.VM Update - cpu add Online:
# uxencli vm-update ad9275d2-92df-40be-9fc2-de10457d3c1e 2 1024 2048
Success
Online으로 cpu가 core가 올라가지 않는다.
reboot으로도 변경 되지 않는다.
shutdown 이후 start로 다시 켜줘야 정상 반영됨.
16.VM Update - cpu Delete Online:
# uxencli vm-update ad9275d2-92df-40be-9fc2-de10457d3c1e 1 1024 2048
Success
Online으로 cpu가 줄어 들지 않는다.
cpu add 처럼 Online으로 delete 반영 불가
reboot으로도 안된다. shutdown, start를 거쳐야 한다.
16.VM Update - mem add Online:
# uxencli vm-update ad9275d2-92df-40be-9fc2-de10457d3c1e 1 2048 2048
Success
MEM ADD는 바로 반영됨
16.VM Update - mem delete Online:
# uxencli vm-update ad9275d2-92df-40be-9fc2-de10457d3c1e 1 1024 2048
Success
mem을 온라인으로 줄이면 위 그림과 같이 조금씩 줄어드는 모습을 확인 가능.
16.VM Update - mem Offline Add:
# uxencli vm-update ad9275d2-92df-40be-9fc2-de10457d3c1e 1 2024 2048
Success
mem add Offline으로 가능.
16.VM Update - mem Offline Delete:
# uxencli vm-update ad9275d2-92df-40be-9fc2-de10457d3c1e 1 1024 2048
Success
mem delete offline으로 가능.
mem 수정은 자유로우나 cpu 수정은 자유롭지 못한것으로 보인다.
17.VM vif Add - Online,Offline:
# uxencli vm-vif-add ad9275d2-92df-40be-9fc2-de10457d3c1e xenbr1
Success
# uxencli vm-vif-list ad9275d2-92df-40be-9fc2-de10457d3c1e
ID VIF_NAME BRIDGE MAC
31 2zrzn0xd1 xenbr1 00:16:3E:BD:ED:6B
30 tng7fs0bg xenbr0 00:16:3E:63:97:8E
36 05j4mliyz xenbr1 00:16:3E:39:C9:CD
18.VM vif Delete:
g# uxencli vm-vif-del ad9275d2-92df-40be-9fc2-de10457d3c1e 30
Failure (Bad Request) : {"message":"The VM should not be running.","result":114}
vif add는 Online,Offline 모두 가능하며, delete는 vm Offline에서만 가능 하다.
19.VM vif List
위의 17.번 내용에 List 출력 있음.
20.VM Storlink Migrate - Online:
# uxencli vm-smigrate ad9275d2-92df-40be-9fc2-de10457d3c1e 2
Success
Storlink를 옮겨 가는것으로 경로를 변경하는것이다.
disk의 경로 이동이 잘 되었나 확인하기 위해 disk-list를 볼려니 DB 에러가 나타난다.:
# uxencli vm-disk-list ad9275d2-92df-40be-9fc2-de10457d3c1e
Traceback (most recent call last):
File "/opt/uxen3/script/uxencli", line 1175, in <module>
cli(obj={})
File "/usr/local/lib/python3.4/dist-packages/click/core.py", line 716, in __call__
return self.main(*args, **kwargs)
File "/usr/local/lib/python3.4/dist-packages/click/core.py", line 696, in main
rv = self.invoke(ctx)
File "/usr/local/lib/python3.4/dist-packages/click/core.py", line 1060, in invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
File "/usr/local/lib/python3.4/dist-packages/click/core.py", line 889, in invoke
return ctx.invoke(self.callback, **ctx.params)
File "/usr/local/lib/python3.4/dist-packages/click/core.py", line 534, in invoke
return callback(*args, **kwargs)
File "/usr/local/lib/python3.4/dist-packages/click/decorators.py", line 17, in new_func
return f(get_current_context(), *args, **kwargs)
File "/opt/uxen3/script/uxencli", line 836, in vm_disk_list
format(data['uuid'], data['storlink'], data['size'],
TypeError: string indices must be integers
VM을 shutdown,start 를 거치니 정상적으로 disk-list 출력됨.
20.VM Storlink Migrate - Offline:
# uxencli vm-smigrate ad9275d2-92df-40be-9fc2-de10457d3c1e 1
Failure (Bad Request) : {"message":"The VM should run for storage migration.","result":203}
VM 미구동 상태에서 smigrate 가 불가 한것으로 보인다. 구동후 다시 시도:
# uxencli vm-start ad9275d2-92df-40be-9fc2-de10457d3c1e
Success
# uxencli vm-smigrate ad9275d2-92df-40be-9fc2-de10457d3c1e 1
Success
disk 이미지가 유실 되었다. smigrate는 사용하면 안되는것으로 보인다.
21.VM Migrate - Online:
# worthy -> dwade
# uxencli vm-migrate f9423a1a-2a51-47b9-be0c-8b1fffa4935c E0A697BE-C47E-DD11-98FB-0023540D61DA
Failure (Bad Request) : {"message":"Fail to migrate The VM.","result":219}
# dwade -> worthy
# uxencli vm-migrate 6d8229ad-559d-4421-9cb6-0bc5a5e136b8 A064D172-E07E-DD11-91FE-0023541104C2
Failure (Bad Request) : {"message":"Fail to migrate The VM.","result":219}
똑같은 PC의 CPU? 체계 이면 Migrate가 된다고 들었다. 다르면 안될 가능성이 있다고 한다.
위의 상태로는 안되는것으로 보인다.
dwade cpu: Pentium(R) Dual-Core CPU E6300 @ 2.80GHz
worthy cpu: Intel(R) Core(TM)2 Quad CPU Q9400 @ 2.66GHz
Storlink 관련기능은 dwade가 아닌 worthy 에서 진행
Storlink 관련기능
1.Storelink Add:
# uxencli storlink-add worthy_local_test /data/test "worthy test storlink" lo fl false
Success
2.Storelink Del:
# uxencli storlink-del 20
Success
3.Storlink List:
# uxencli storlink-list
ID NAME LINK TYPE LEVEL SHARED FREE SIZE
14 nfs-vm /nfs-vm NFS FL 1 7083 9324
6 worthy_local_gvm /data/gvm/ LO FL 0 433941 466221
7 worthy_local_vm /data/vm/ LO FL 0 433941 466221
15 iscsi-gvm /iscsi-gvm ISC FL 1 28146 30720
16 aoe-vm /dev/aoe_disk LO BL 1 99996 99996
17 aoe-test /dev/aoe_test FC BL 1 0 102396
18 worthy_data2 /data2 LO FL 0 305543 307050
19 aoe-vm2 /dev/aoe_disk2 FC BL 1 207836 299996
4.Storelink Update:
# uxencli storlink-update 21 worthy_local_test1 /data/test "worthy test storlink1" lo fl false
Success
Snapshot관련 기능
Snapshot에 관한 설명이 조금 필요.
시스템 고장으로 정지했을때 복구 시점을 만들어 주는것이다.
전체 백업이 아닌 중간지점에 습냅샷을 찍어두는것으로 이해가 된다.
그냥 백업을 하면 되지? 스냅샷을 사용할 이유가 있나?
대용량, 큰 시스템의 백업은 많은 시간도 소요 되지만,
백업 중인 디렉토리의 파일을 사용자가 이동하게 된다면 해당 파일은 백업미디어에서 완전 분실 상태가 되어 안전한 백업이 되지 못함.
1.Snapshot Add:
# uxencli snapshot-add f9423a1a-2a51-47b9-be0c-8b1fffa4935c snap_test1 21 "snapshot test1"
Success
[2019-06-26 16:27:59] DEBUG [api:637] (True, [{'format': 'qcow2', 'order': 1, 'uuid': 'e8aade96-e42c-4052-8fa7-a9a41269b595', 'desc': 'Run snapshot disk(e8aade96-e42c-4052-8fa7-a9a41269b595) created from disk(428a24a6-7e1b-4e85-9887-32b109e6fddf)', 'type': 'RS', 'size': 30720}, {'format': 'qcow2', 'order': 1, 'uuid': '95c346c8-b983-4d27-83d5-5cf960a33466', 'desc': 'Saved snapshot disk(95c346c8-b983-4d27-83d5-5cf960a33466) created from disk(428a24a6-7e1b-4e85-9887-32b109e6fddf)', 'type': 'SS', 'size': 30720}])
[2019-06-26 16:27:59] DEBUG [api:2005] [{'format': 'qcow2', 'order': 1, 'uuid': 'e8aade96-e42c-4052-8fa7-a9a41269b595', 'desc': 'Run snapshot disk(e8aade96-e42c-4052-8fa7-a9a41269b595) created from disk(428a24a6-7e1b-4e85-9887-32b109e6fddf)', 'type': 'RS', 'size': 30720}, {'format': 'qcow2', 'order': 1, 'uuid': '95c346c8-b983-4d27-83d5-5cf960a33466', 'desc': 'Saved snapshot disk(95c346c8-b983-4d27-83d5-5cf960a33466) created from disk(428a24a6-7e1b-4e85-9887-32b109e6fddf)', 'type': 'SS', 'size': 30720}]
위의 로그 결과로 보아 Type: rs, ss 가 정상적으로 생성된것으로 확인됨.
그런데 Type: rs, ss는 무엇인가? 흠…
2.Snapshot Delete
3.4.5.를 실행후 Delete 시도:
# uxencli snapshot-del f9423a1a-2a51-47b9-be0c-8b1fffa4935c 10238a18-4a38-4f97-a49b-01f3aa74dbd8
Failure (Bad Request) : {"message":"The VM should not be running.","result":114}
# uxencli snapshot-del f9423a1a-2a51-47b9-be0c-8b1fffa4935c d80bbb06-2d88-43a8-9983-162b2c5530b5
Failure (Bad Request) : {"message":"The VM should not be running.","result":114}
VM 구동중일때 Delete 가능한것으로 보임.
shutdown 이후 시도:
# uxencli snapshot-del f9423a1a-2a51-47b9-be0c-8b1fffa4935c d80bbb06-2d88-43a8-9983-162b2c5530b5
Failure (Bad Request) : {"message":"Snapshot(d80bbb06-2d88-43a8-9983-162b2c5530b5) is a parent of other snapshots.","result":114}
다른 스냅샷의 부모 다???:
# uxencli snapshot-list f9423a1a-2a51-47b9-be0c-8b1fffa4935c
UUID NAME PARENT
10238a18-4a38-4f97-a49b-01f3aa74dbd8 restored snapshot name(snap_test1) f9423a1a-2a51-47b9-be0c-8b1fffa4935c/d80bbb06-2d88-43a8-9983-162b2c5530b5
d80bbb06-2d88-43a8-9983-162b2c5530b5 snap_test1 f9423a1a-2a51-47b9-be0c-8b1fffa4935c
그러면 restored.. 시점 snapshot-delete 해 보겠다.:
# uxencli snapshot-del f9423a1a-2a51-47b9-be0c-8b1fffa4935c 10238a18-4a38-4f97-a49b-01f3aa74dbd8
Success
restore 된 스냅샷이 있으면 restore 부터 제거해 줘야 되는것으로 확인.
3.Snapshot Disk List:
# uxencli snapshot-disk-list f9423a1a-2a51-47b9-be0c-8b1fffa4935c d80bbb06-2d88-43a8-9983-162b2c5530b5
DISK_UUID STORLINK SIZE FORMAT TYPE ORDER
e8aade96-e42c-4052-8fa7-a9a41269b595 21 30720 qcow2 RS 1
95c346c8-b983-4d27-83d5-5cf960a33466 21 30720 qcow2 SS 1
4.Snapshot List:
# uxencli snapshot-list f9423a1a-2a51-47b9-be0c-8b1fffa4935c
UUID NAME PARENT
d80bbb06-2d88-43a8-9983-162b2c5530b5 snap_test1 f9423a1a-2a51-47b9-be0c-8b1fffa4935c
5.Snapshot Restore:
# uxencli snapshot-restore f9423a1a-2a51-47b9-be0c-8b1fffa4935c d80bbb06-2d88-43a8-9983-162b2c5530b5
Failure (Bad Request) : {"message":"The VM should not be running.","result":114}
Online 상태에선 불가 그래서 shutdown 이후 시도.:
# uxencli snapshot-restore f9423a1a-2a51-47b9-be0c-8b1fffa4935c d80bbb06-2d88-43a8-9983-162b2c5530b5
Success
# uxencli snapshot-list f9423a1a-2a51-47b9-be0c-8b1fffa4935c
UUID NAME PARENT
10238a18-4a38-4f97-a49b-01f3aa74dbd8 restored snapshot name(snap_test1) f9423a1a-2a51-47b9-be0c-8b1fffa4935c/d80bbb06-2d88-43a8-9983-162b2c5530b5
d80bbb06-2d88-43a8-9983-162b2c5530b5 snap_test1 f9423a1a-2a51-47b9-be0c-8b1fffa4935c
restore로 인해 NAME에 restored… 포인트가 생성된것을 확인.
여기서 부터 GVM 관련 기능.
1.GVM Add:
# uxencli gvm-add worthyTestGvm debian x64 "worthyTestGvm" 21 53e60b6b-5dd5-4f0a-9e9e-b26d90fbc513 qcow2
Success
2.GVM Copy from VM:
# uxencli gvm-copyfromvm f9423a1a-2a51-47b9-be0c-8b1fffa4935c test_copyfromvm 21 "copy"
Failure (Bad Request) : {"message":"The VM should be stopped.","result":203}
VM 중지하고 다시 시도:
# uxencli gvm-copyfromvm f9423a1a-2a51-47b9-be0c-8b1fffa4935c test_copyfromvm 21 "copy"
Success
Copy본으로 부팅 유무 확인을 위해 vm-add 이후 부팅:
# uxencli vm-add copyTest 15dfd489-5446-47d2-8eed-def949c485e7 21 1 1024 2048 "copyT"
Success
# uxencli vm-start e7ed04bb-60f1-41f0-b0fd-0fbd795f3335
Success
정상작동!!!!
3.GVM Delete - GVM 관련 1.2.4.5.6.을 모두 실행후 delete:
# uxencli gvm-del 15dfd489-5446-47d2-8eed-def949c485e7
Failure (Bad Request) : {"message":"VM linked to the template exists.","result":100}
위의 GVM으로 생성된 VM이 있으면 delete가 안되는것으로 보임
관련 VM 제거후 시도:
# uxencli gvm-del 15dfd489-5446-47d2-8eed-def949c485e7
Success
관련 vm 제거후 gvm 제거 성공!!
4.GVM Disk List:
# uxencli gvm-disk-list a5c3a910-d777-4c55-9d2d-73b0c62dac22
DISK_UUID STORLINK SIZE FORMAT ORDER
53e60b6b-5dd5-4f0a-9e9e-b26d90fbc513 21 30720 qcow2 1
5.GVM List:
# uxencli gvm-list
UUID NAME SIZE OS ARCH
909f64a8-d476-4d51-b6c0-0c2edc5988b1 jaragvm 30720 DEBIAN X64
c5dfd089-d4d9-4c04-92ab-176248055df1 jennie_aoe_gvm 30720 DEBIAN X64
bd4d84ec-9ea5-4820-8e0c-8d327e482dfe jennie_nfs_gvm 30720 DEBIAN X64
f8c19f91-ffa8-4350-b5a8-780211074366 worthy_debian9.9 30720 DEBIAN X64
1b14c1cd-a374-406c-b1e4-5be320c1cad6 iscsi-gvm-debian9.9 30720 DEBIAN X64
a5c3a910-d777-4c55-9d2d-73b0c62dac22 worthyTestGvm 30720 DEBIAN X64
6.GVM Update:
# uxencli gvm-update 15dfd489-5446-47d2-8eed-def949c485e7 TTtest debian x64 "TTT"
{"desc": "TTT", "name": "TTtest", "os_arch": "X64", "os": "DEBIAN"}
Success
PM관련 기능
1.PM Information:
# uxencli pm-info
UUID : A064D172-E07E-DD11-91FE-0023541104C2
Name : worthy
CPU : 4
Memory : 8191
Networks : [ifname] [ip] [mac]
xenbr0 192.168.0.38 00:e3:3d:e8:00:be
xenbr1 10.0.0.38 00:23:54:11:04:c2
Created : 2019-05-28T06:53:40.070080Z
Updated : 2019-06-14T00:45:33.758190Z
2.PM List:
# uxencli pm-list
UUID NAME CPU MEM
A064D172-E07E-DD11-91FE-0023541104C2 worthy 4 8191
E0A697BE-C47E-DD11-98FB-0023540D61DA dwade 2 6143
uxenapi node에 가입된 PM들의 정보가 모두 나온다.
3.PM State:
# uxencli pm-stat
UUID : A064D172-E07E-DD11-91FE-0023541104C2
Name : worthy
Total CPU : 4
Used CPU : 5
Hyperthread : off
CPU Ratio : 125.0 %
Total Memory : 8191
Used Memory : 5119
Running VMs : 3
Networks : [ifname] [rx_sum] [tx_sum]
total 12018975514 2552684375
xenbr1 4795256568 1047308430
xenbr0 301980854 50415042
eth0 1747870919 49684202
eth1 5173867173 1405276701
Created : 2019-05-28T06:53:40.070080Z
Updated : 2019-06-14T00:45:33.758190Z
Backup 관련 기능
1.Backup Add:
# uxencli backup-add f9423a1a-2a51-47b9-be0c-8b1fffa4935c backup_test 21 "backup test"
Success
2.Backup Delete 는 Backup 관련기능 모두 수행후 진행 함:
# uxencli backup-del f9423a1a-2a51-47b9-be0c-8b1fffa4935c 9cc67e6a-26a6-4b14-be49-7ea7b24949f9
Success
백업 이미지 정상적으로 삭제 확인 완료.
3.Backup Disk List:
# uxencli backup-disk-list f9423a1a-2a51-47b9-be0c-8b1fffa4935c 1f8b2a27-b6e3-4516-815c-3fa4e89dd59b
DISK_UUID STORLINK SIZE FORMAT ORDER
50491138-80c0-4c49-adff-10e8d25ac39e 21 30720 qcow2 1
4.Backup List:
# uxencli backup-list f9423a1a-2a51-47b9-be0c-8b1fffa4935c
UUID NAME SIZE CREATED
9cc67e6a-26a6-4b14-be49-7ea7b24949f9 - 30720 2019-06-27T02:21:55.043980Z
1f8b2a27-b6e3-4516-815c-3fa4e89dd59b - 30720 2019-06-27T02:15:38.322701Z
5.Backup Restore:
# uxencli backup-restore f9423a1a-2a51-47b9-be0c-8b1fffa4935c 1f8b2a27-b6e3-4516-815c-3fa4e89dd59b
Failure (Bad Request) : {"message":"The VM should be stopped.","result":203}
VM 구동중일땐 불가능 한것으로 보인다. shutdown 이후 시도:
# uxencli backup-restore f9423a1a-2a51-47b9-be0c-8b1fffa4935c 1f8b2a27-b6e3-4516-815c-3fa4e89dd59b
Success
backup-restore 이후 이전 백업 이미지 상태로 되돌아가는 것을 확인.