iOrchard

Burrito 2.1.3 is released

Tue, 29 Oct 2024 00:00:00 +0900

Burrito 2.1.3 is released

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)

Burrito: kubernetes certificates are not renewed automatically

Mon, 28 Oct 2024 00:00:00 +0900

Burrito: kubernetes certificates are not renewed automatically

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 2.1.2 is released

Tue, 24 Sep 2024 00:00:00 +0900

Burrito 2.1.2 is released

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)

Demo: Provision K8S cluster on PBOS using pulumi

Thu, 22 Sep 2022 00:00:00 +0900

Demo: Provision K8S cluster on PBOS using pulumi

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

Demo: PBOS Installation

Thu, 23 Sep 2021 00:00:00 +0900

Demo: PBOS Installation

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 - VM High Availability for OpenStack

Thu, 04 Mar 2021 00:00:00 +0900

OkiDoki - VM High Availability for OpenStack

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 - a test robot suite for OpenStack platform

Thu, 04 Mar 2021 00:00:00 +0900

Sparring - a test robot suite for OpenStack platform

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

쿠버네티스 컨테이너 인터페이스 식별하는 방법

Wed, 29 Jan 2020 00:00:00 +0900

쿠버네티스 컨테이너 인터페이스 식별하는 방법

쿠버네티스 환경에서 특정 컨테이너의 인터페이스를 모니터할 일이 생겼는데,

해당 컨테이너 인터페이스의 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:  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:  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:  mtu 1500 qdisc noqueue state UP group default

cali29544dc48cd인터페이스임을 알 수 있다.

reference

https://www.digitalocean.com/community/tutorials/how-to-inspect-kubernetes-networking

GitLab 간략 사용법

Tue, 30 Jul 2019 00:00:00 +0900

GitLab 간략 사용법

[개요]

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 "support@iorchard.co.kr"

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 기능시험

Mon, 01 Jul 2019 00:00:00 +0900

테스트 서버 UXEN3 기능시험

[개요]

브라운스톤 사무실 이사후 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
nfs-vm               /nfs-vm                              NFS  FL    1      7083       9324
worthy_local_gvm     /data/gvm/                           LO   FL    0      433941     466221
worthy_local_vm      /data/vm/                            LO   FL    0      433941     466221
iscsi-gvm            /iscsi-gvm                           ISC  FL    1      28146      30720
aoe-vm               /dev/aoe_disk                        LO   BL    1      99996      99996
aoe-test             /dev/aoe_test                        FC   BL    1      0          102396
worthy_data2         /data2                               LO   FL    0      305543     307050
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가 안되는것으로 보임

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 이후 이전 백업 이미지 상태로 되돌아가는 것을 확인.