HashiCorp Vault와 UAG REST API를 활용하여 UAG의 외부 인증서를 자동으로 갱신하는 방법을 알아봅니다.

앞으로 TLS 인증서의 최대 유효기간은 47일까지 줄어들 예정이므로, 인증서 자동 갱신은 선택이 아닌 필수입니다.

https://rollingwhale.notion.site/Horizon-UAG-w-HashiCorp-Vault-2b83f4b98ad380ac96acd877eb9a12d7

proxmox 호스트하고 ping도 문제 없고 실행중인 vm도 잘 동작합니다.

그런데 ui에 접속하려고 하면 응답이 없네요.

이런 경험 있으신 분들 도움 부탁드립니다.

 이번에도 분량 + 포매팅 문제로 Notion을 사용했습니다.

VMware by Broadcom이 VCF에 집중함에 따라, VMware 엔지니어들은 이제 VCF를 스터디해야 합니다.

하지만 VCF의 최소 요구 사양이 높아, 대부분의 경우 Holodeck에 의존한 nested 환경에서 VCF를 사용할 수 밖에 없었습니다.

이번에 홈 랩 환경에 VCF 9.0.1을 배포하면서, 실제 프로덕션 배포 환경에서 주의해야 할 점과 사전 요구사항을 정리했습니다.

자세한 내용은 링크를 참조하십시오.

가상화 하이퍼바이저 설치하고 VM설정하다 보니 시간 잘 가네요.

PROXMOX 설치하는데 하드웨어적으로 문제가 좀 있어서 트러블 슈팅하느라 오래 걸렸습니다. 

아래도 적었지만 인텔랜카드 죽는 문제, msi x99sli plus 보드에서 ECC 램을 반 밖에 인식 못하는 문제

그래픽 카드는 쓸 데가 마땅치 안았던 P106-100 그래픽 출력이 없는 채굴용 GPU를 윈도우 원격데스크탑 가속용으로 쓰려고 설치

패스스루 설정하고 그래픽 카드 드라이버 올려서 인식 시키는데까지 성공.

패스스루는아래 포럼글 참고. 7버전일 때 보다는 간단해 진듯.
https://forum.proxmox.com/threads/pci-gpu-passthrough-on-proxmox-ve-8-installation-and-configuration.130218/

P106-100 패치 드라이버는 아래 링크 참고

https://github.com/dartraiden/NVIDIA-patcher?tab=readme-ov-file#security-and-transparency

관리 화면에서 이것 저것 작업 하다가 갑자기 먹통이 됩니다. 

원인을 파악하는데 시간이 좀 오래 걸렸습니다. 

하드웨어 문제인줄 알았는데, 콘솔은 또 정상적으로 동작하더군요. 

관리 웹이 로딩 중이라고 뜨면서 접속이 안되는 현상... 

VM 시작 전에는 또 괜찮고 ... VM 올리고 쓰다보면 현상이 발생합니다. 

현상이 발생하고 콘솔에서 dmesg로 로그를 보면 아래와 같은 에러가 뜹니다. 

e1000e eno1: Detected Hardware Unit Hang:

https://forum.proxmox.com/threads/intel-nic-e1000e-hardware-unit-hang.106001/
위 사이트 참고해서 해결했습니다.

 post-up ethtool -K eno1 tso off gso off

검색해보니 대역폭을 초과하면 끊길 수 있는데 호스트도 끊긴다는 글이 있더군요 

인터넷 데이터 사용이 확 올라가서 대역폭을 초과 했을지는 모르지만 저는 호스트는 안 끊깁니다 

이 vm 에 설치한 파이어폭스에 창 여러개와 탭 여러개가 있습니다 파폭을 키면 데이터 받는 양이 확 올라가는 게 보입니다 

하지만 계속 파폭에서 웹서핑을 하면 안 끊기는데 잠깐 그대로 두고 딴 짓 하다가 와보면 브라우저에서 어디를 접속하든 페이지가 안 뜹니다 

인터넷 연결이 없다고 나옵니다 

vm 을 재시동 하면 다시 됩니다 그리고 브라우저 안 키고 그냥 이 vm 안에 설치한 온라인 게임을 하거나 열린 창 하나에 탭 3개 정도 있는 Edge 브라우저만 열면 이거로 웹서핑 좀 하다가 한참 내버려둬도 인터넷이 안 끊깁니다 

창과 탭이 엄청 많은 파이어폭스 브라우저를 열 때 대역폭을 초과해서 끊기는 현상이 맞는건가 싶기도 하고 암튼 이리 저리 해결책을 찾아보다가 좀 쉬워보이는(?) 방법으로 시도를 해봤습니다

위 사진에서 빨간 선으로 둘러싼 부분을 체크 표시하고 그 아래에 hyper-v 의 네트워크를 선택해줬습니다 

이렇게 하고나니 아직까지는 인터넷 끊기는 현상이 없습니다 

그런데 이게 옳은 해결법인지 궁금합니다 

그리고 이렇게 하는 게 혹시 해킹 같은 거에 취약한 문제가 있지는 않나 그 부분도 궁금합니다 

조언 좀 부탁드리겠습니다 

감사합니다 

버벅임이 있습니다 

코어랑 메모리 설정이 잘못된걸까요?

Ok

- REINSTALL=ALL를 사용하지 말 것, 변경사항 없이 Return code 0 로 종료됩니다

- Horizon Agent 설치 시 활성화된 Horizon 세션이 없어야 함, 세션 로그오프를 권장합니다.

- ADDLOCAL의 경우, 최신 버전에서 업데이트 된 인자를 사용할 것,
https://docs.omnissa.com/ko-KR/bundle/Desktops-and-Applications-in-HorizonVmulti/page/SilentInstallationPropertiesforHorizonAgentforWindows.html 에서 확인 가능합니다.

제 환경에서 사용한 인자값은 다음과 같습니다:

/s 'v"/qn ADDLOCAL=Core,NGVC,RTAV,HznVaudio,HznVidd2,BlastUDP,PerfTracker,PSG REBOOT=ReallySuppress"

기존 버전과 비교해, V4V, PCoIP 컴포넌트가 제거되었고, Vaudio와 Vidd 컴포넌트에 Hzn 이라는 접두사가 추가되었습니다.

위 명령어 구문에는 없지만, 스토리지 리다이렉션 컴포넌트 또한 이름이 달라졌습니다.

설치 전에 기존 VMware Horizon Agent를 수동으로 제거할 필요는 없습니다.

해상도가 1024*768 이 범위에서 고쳐지지가 않네요 ㅠㅠㅠ

혹시 가능하신분 꼭 사례 드리고 싶습니다... 도와주세요 ㅠㅠㅠ

이세기

10년째 OpenStack 관련 프로젝트를 하면서 회사를 유지해 오고 있습니다. 최근 2-3년동안은 Proxmox 도 같이 하고 있지만요. 오픈인프라 코리아 커뮤니티에서 주로 활동을 하면서 염원이자 목표이기도 했던 초보자/입문자들을 위한 OpenStack 자료를 만드는것에 저도 참여를 하고 싶었었는데, 마침 저도 현재 계약관계로 엮여서 일하고 있는 곳에서 OpenStack을 처음부터 경험 시켜드려야 하는 분들이 3-4명 정도 계시는 바람에 자료를 만들어야 하는 필요성이 생겨 자료를 하나 만들어 보자는 결심을 하게 되었습니다.

https://forum.openinfra-kr.org/t/openstack/227

2cpu 커뮤니티 분들을 위해서는 따로 매뉴얼에 바로 접근할 수 있는 링크 하나 드립니다. ^^. 

혹시 OpenStack에 관심이 있으신 분들에게 조금이나마 도움이 되길 바라며,  혹시나 자료의 내용에 대한 부분이나 의견 주시면 감사하겠습니다.

다양한 의견이 있으면 당연히 더 좋은 가이드가 될테니까요.

https://smsolutions.slab.com/public/posts/ogjs-104-%EC%B9%9C%EC%A0%88%ED%95%9C-%EA%B9%80%EC%84%A0%EC%9E%84-5r4edxq3?shr=gm6365tt31kxen7dc4d530u0

Firecracker 한줄 정의

AWS가 서버리스·컨테이너 워크로드를 “초고속 + 초경량 + 강격리”로 돌리려고 만든 KVM 기반 VMM(가상머신 모니터). 리눅스 커널만 최소 장치로 올리는 microVM을 띄워서 컨테이너급 속도와 VM급 격리를 동시에 노리는 구조야. 공식 수치로 부팅 < 125ms, 오버헤드 < 5MiB, 호스트당 초당 최대 150개 생성을 목표로 설계되었고, Lambda/Fargate에 실제 적용돼 있어. firecracker-microvm.github.ioUSENIXAmazon Science

왜 만들었나 / 어디에 쓰이나

• 문제의식: 컨테이너는 커널을 공유해서 속도/유연성은 좋지만 격리면에서 VM보다 약함. 서버리스 다중 테넌트에서 보안/밀도/속도를 모두 만족하려고 Firecracker를 별도로 설계. USENIX

• 적용: AWS Lambda, Fargate가 대규모로 사용. 한 서버에서 수천 microVM을 동시에 실행해 요청을 처리. USENIXAmazon Science

• 성능/밀도 목표(공개 수치): microVM 당 <5MiB 메모리 오버헤드, <125ms에서 유저 공간/앱 코드 진입, 초당 150개 microVM 생성. USENIXfirecracker-microvm.github.io

핵심 아키텍처 (구성요소)

• VMM (Rust): 유저 공간에서 KVM을 사용해 microVM 생성·관리. 장치 모델 최소화(virtio-net, virtio-blk, virtio-vsock, 시리얼 콘솔, 최소 키보드 컨트롤러만)로 공격면을 극소화. firecracker-microvm.github.io

• REST API: 유닉스 소켓을 통해 vCPU/메모리/디스크/네트워크/레이트리미터/메타데이터 서비스 등을 구성 후 부팅. GitHub

• Jailer: chroot, PID/네임스페이스 분리, 권한 드롭, seccomp-BPF(화이트리스트 24개 syscalls)로 2중 격리. 운영 배포에서 권장. USENIX

• 스냅샷/복원: 실행 중 VM 상태를 저장/복원해 콜드스타트 지연을 더 줄이는 운영 패턴(예: Lambda SnapStart와 철학 유사). GitHubAWS 문서

컨테이너 / 전통 VM / Firecracker 비교

수치/제약의 근거: 공식 사이트와 NSDI 논문(“BIOS/PCI/라이브 마이그” 미지원), 장치 5종, 부팅/오버헤드/생성률. firecracker-microvm.github.ioUSENIX

장점과 트레이드오프

장점

• 보안/격리: 하드웨어 가상화 + 최소 장치 모델 + jailer(seccomp, chroot, 네임스페이스). USENIX

• 속도/밀도: 컨테이너에 근접한 스타트업 + 낮은 메모리 풋프린트로 고밀도 배치. firecracker-microvm.github.io

• 운영 제어: 네트워크/스토리지 레이트 리미터 내장, 메타데이터 서비스 제공. firecracker-microvm.github.io

트레이드오프

• 기능 최소화: BIOS/PCI/라이브 마이그레이션 미지원, Windows 게스트 부팅 불가(의미 있는 변경 없이는). USENIX

• 네트워킹 셋업 필요: TAP/브리지 구성 등 호스트 네트워킹 지식 요구. Actuated

• 오케스트레이션은 별도: Firecracker는 QEMU 대체 포지션이지 Docker/K8s 대체가 아님. 컨테이너 생태계와 연동(firecracker-containerd 등)로 해결. USENIXGitHub

빠르게 맛보기: “Hello microVM” 로컬 실행 흐름

전제: 리눅스 호스트, 하드웨어 가상화( /dev/kvm ), 커널 4.14+, x86_64/ARM64. firecracker-microvm.github.io

1. 바이너리 설치(또는 빌드)

• 최신 릴리스 다운로드(현재 v1.12.1이 최신 릴리스로 표기). 또는 소스 빌드:

  git clone https://github.com/firecracker-microvm/firecracker cd firecracker tools/devtool build

  빌드 산출물 경로는 README의 안내 참고. GitHub

2. 커널 & 루트FS 준비

• 게스트 커널 이미지(vmlinux)와 최소 루트FS(ext4)를 준비. (공식 가이드/배포판 도구/직접 빌드 활용 가능) GitHub

3. Firecracker 프로세스 시작(REST 소켓 노출)

다른 터미널에서 REST 호출로 설정을 밀어넣어 부팅. 짓보 - 개발자의 오타크

4. 머신/부팅/디스크 설정 + 부팅

REST API로 구성/부팅하는 흐름은 공식 README/가이드가 기준. GitHub

5. 운영 모드

• 프로덕션에서는 jailer로 chroot/네임스페이스/권한드랍/seccomp를 적용해 실행. GitHubUSENIX

운영에 투입하려면 (옵션)

• 컨테이너 생태계 연동: firecracker-containerd 사용 시 컨테이너당 microVM을 자동 관리(컨테이너드와 vsock 에이전트 연계). CI/CD, 멀티테넌트 SaaS 격리에 유용. GitHub

• 스냅샷/복원: 장시간 초기화 있는 워크로드(예: 자바 런타임)에서 cold start를 크게 낮추는 패턴. Lambda SnapStart 문서의 아이디어와 맞닿음. GitHubAWS 문서

• 호스트 하드닝: Firecracker 팀이 권장하는 프로덕션 호스트 설정 문서 참고(커널 완화, SMT 비활성 등). NSDI 논문에 사이드채널 대응 권고가 정리되어 있음. GitHubUSENIX

언제 Firecracker를 택할까?

• 다중 테넌트 환경에서 컨테이너보다 더 강한 격리가 필요하지만 속도/밀도도 포기 못할 때.

• 서버리스/잡성(短命) 워크로드(요청 단위 인스턴스)나 불신 코드 실행 샌드박스(온라인 저지/코드 실행 서비스/멀티테넌트 CI) 등에 특히 적합. USENIXStan's blog

• 반대로 Windows 게스트, 풍부한 가상 장치/라이브 마이그레이션 등 전통적 VM 기능이 필수라면 QEMU/KVM 계열이 더 적합. USENIX

추가로 볼만한 1차 자료

• 공식 사이트(개요, 사양, 장치 5종, <125ms/<5MiB, 메타데이터/레이트리미터/Jailer): firecracker-microvm.github.io

• NSDI’20 논문(설계 철학, 수치, 보안·성능 평가, “무엇을 빼었는가”): USENIX

• Amazon Science 블로그(운영 스케일, “초당 150개·수천 동시”): Amazon Science

• GitHub README(API/기능 목록, 빌드·릴리스, v1.12.1): GitHub

• firecracker-containerd(컨테이너드 연동): GitHub

• 스냅샷/복원 문서: GitHub

Q&A :

Firecracker는 어떤 워크로드에 가장 적합하며, 왜 이를 선택하는지 궁금합니다

Firecracker는 특히 보안, 속도, 밀도가 중요한 워크로드에 가장 적합합니다. 기존 가상 머신(VM)의 강력한 격리 기능과 컨테이너의 가벼움을 모두 필요로 하는 현대적인 클라우드 환경에 최적화되어 있습니다.

Firecracker가 가장 효과적으로 사용되는 워크로드와 그 이유는 다음과 같습니다.

1. 서버리스 컴퓨팅 (예: AWS Lambda)

서버리스 함수는 이벤트가 발생할 때만 일시적으로 실행되는 짧은 생애주기를 가집니다.

• 선택 이유:

  • 빠른 시작 속도: 사용자의 요청에 즉각적으로 응답하기 위해 수십 밀리초(ms) 내에 컴퓨팅 환경이 준비되어야 합니다. Firecracker의 microVM은 125ms 이내에 부팅이 가능하여 이러한 요구사항을 완벽히 충족합니다.

  • 강력한 보안 및 격리: 서버리스 환경에서는 수많은 고객의 코드가 동일한 물리 서버에서 실행됩니다. Firecracker는 하드웨어 가상화 기반의 microVM을 사용하여 각 함수를 완벽하게 격리함으로써, 한 고객의 코드가 다른 고객에게 영향을 미치는 것을 원천적으로 차단합니다.

  • 높은 자원 효율성: 각 microVM은 5MB 미만의 매우 적은 메모리만 추가로 사용하므로, 단일 서버에 수천 개의 함수를 동시에 실행할 수 있습니다. 이는 서비스 제공자 입장에서 비용 효율성을 극대화합니다.

2. 컨테이너 워크로드 (예: AWS Fargate)

컨테이너는 배포가 빠르고 가볍지만, 호스트 운영체제의 커널을 공유하기 때문에 다중 테넌트(multi-tenant) 환경에서는 보안에 대한 우려가 있을 수 있습니다.

• 선택 이유:

  • 보안 강화: Firecracker는 각 컨테이너 또는 컨테이너 그룹(Pod)을 자체 microVM 내에서 실행하여, 컨테이너에 VM 수준의 강력한 격리 계층을 추가해 줍니다. 이를 통해 커널 취약점을 이용한 공격으로부터 호스트와 다른 컨테이너를 보호할 수 있습니다.

  • 성능 유지: 무거운 전체 VM을 사용하는 대신 경량 microVM을 사용하므로, 보안을 강화하면서도 컨테iner의 장점인 빠른 시작과 낮은 오버헤드를 상당 부분 유지할 수 있습니다.

3. CI/CD 파이프라인 및 테스트 자동화

CI/CD(지속적 통합/지속적 배포) 파이프라인에서는 빌드, 테스트, 배포 등 짧고 반복적인 작업들이 실행됩니다.

• 선택 이유:

  • 신속하고 깨끗한 환경: 각 작업(job)을 위해 수초 내에 완전히 격리된 깨끗한 환경을 생성하고, 작업이 끝나면 즉시 폐기할 수 있습니다. 이는 작업 간의 의존성을 없애고 테스트 결과의 일관성을 보장합니다.

  • 효율적인 리소스 사용: 무거운 VM을 매번 생성하고 삭제하는 것에 비해 훨씬 적은 리소스를 사용하므로, 더 많은 작업을 동시에 효율적으로 처리할 수 있습니다.

4. 안전한 코드 실행 샌드박스

신뢰할 수 없는 외부 코드(예: 사용자가 제출한 코드, 플러그인, AI 에이전트가 생성한 코드)를 안전하게 실행해야 하는 모든 시나리오에 적합합니다.

• 선택 이유:

  • 최소한의 공격 표면: Firecracker는 꼭 필요한 기능(네트워크, 스토리지 등)만 최소한으로 제공하여 잠재적인 보안 공격 경로를 크게 줄였습니다.

  • 완벽한 격리: 악성 코드가 실행되더라도 그 영향은 해당 microVM 내부에 완벽히 격리되어 호스트 시스템이나 다른 워크로드에 전혀 영향을 미치지 못합니다.

결론적으로 Firecracker는 **'빠르고, 가벼우면서도, 매우 안전한 격리 환경'**이 필요한 모든 워크로드에 이상적인 솔루션이라고 할 수 있습니다.

인증서 갱신 관련 구글링해서 찾아 봐도 제대로 안되네요. 재설치가 답인거 같아 다운로드 찾아보는데 당최 찾지를 못하겠습니다 ㅠㅠ

혹시 다운로드 가능한 곳 있을까요. 도움 부탁드립니다. 

배워보자 it

정품 사용자분들은 브로드컴 사이트에 토큰 발급 받고 해당 토큰 가지고 URL 다시 등록 해야 됩니다 ㅠㅠ

아오 삽질...

친절한 브로드컴에서 스크립트로 만들어 줘네요 허허허~~

https://knowledge.broadcom.com/external/article/389276

참고로 윈도우 기본 Powershell 안되고 VM CLI 모듈 추가 설치 해줘야 합니다.

https://developer.broadcom.com/powercli

참고들 하세요~~~

업데이트할 AMD Microcode 패키지가 경고 띄우네요

Debian 버전이 bookworm -> trixie으로 바뀌었습니다

일단 눈에 띄는게 ZFS 2.3.3로 바뀌어서 RAIDZ를 지원합니다

또한 GUI에서 메모리 사용량 모니터링시 ZFS ARC의 사용량도 표시되네요

HA관련도 Rule 추가된것같은데, 잘 모르겠습니다

Network쪽은 OpenFabric과 OSPF fabric이 추가되었습니다 (하지만 여전히 이부분은 VMWare 따라갈려면 멀었음)

맨날 삽질만 하고 삽니다

http://www.2cpu.co.kr/hardware_2014/44147
컴 케이스 작다고 불타거나 하지 않아요

hmc로 두 머신을 등록하였고 hmc에서 chsyscfg 명령어로 각각 vios1과 vios2 가상서버를 id 1번으로 Lpar를 생성하였습니다.

이제 hmc에 vios 이미지를 가상CD롬으로 마운트시키고 설치하면 되는줄 알았는데

과정에서 최소1개의 물리? 네트워크 어뎁터를 할당해줘야 한다고 나와서

머신에 기본으로 달려있는 RJ45포트 4개중 1개를 할당하려고하는데 lshwres에서 보이지않습니다.

pci슬롯만 확인이되는데 슬롯에 넣을 카드가 아직 준비된 상태가 아니라서요

pci슬롯에 있는 카드만 할당이 가능한건지 아니면 vmware처럼 vSwitch 생성하고 거기서 끌어와야하는건지 궁금합니다.

에스엠솔루션즈라는 조그만 회사를 운영하고 있는 김선임 이라고 합니다.

2cpu에 계신 분들이 Proxmox의 뉴스에 대해 관심이 많으실것 같아서 원래는 제 개인적인 Linkedin 계정이나, OpenStack 커뮤니티에서 주로 활동을 하였지만 Proxmox 관련한 내용 가지고는 2cpu에서 좀 더 적극적으로 활동해보면 어떨가 싶어 뉴스를 공유 드려봅니다.

현재 Proxmox는 VMware ESXi 를 전면으로 100% 대체하기에는 조금 아쉬운 면모를 가지고 있는것이 현실이죠.

특히 iSCSI 나 SAN Storage를 사용하는 환경이면 더더욱 그랬습니다. 이러한 환경에서 Snapshot이 불가능했던 문제는 Backup과의 연동성과도 이어지면서, VM을 끄지 않으면 백업도 힘들어지는 문제점이 있었죠. 그나마 Proxmox 9.0에 대한 로드맵에서 이러한 문제점들을 해결하기 위한 노력이 보이기 시작해서 다행이라는 생각이 듭니다.

https://pve.proxmox.com/wiki/Roadmap#Proxmox_VE_9.0_BETA_1

• VM snapshots on thick-provisioned LVM storages with snapshots as volume chains (technology preview).

  A new property on thick-provisioned LVM storages enables support for snapshots as volume chains.

  With this setting, taking a VM snapshot persists the current virtual disk state under the snapshot's name and starts a new volume based on the snapshot.

  This enables VM snapshots on shared thick-provisioned LVM storages, as they are often used on LUNs provided by a storage box via iSCSI/Fibre Channel.

  
  

  VM 스냅샷(기술 프리뷰): 볼륨 체인 방식 스냅샷을 사용하는 Thick-provisioned LVM 스토리지 지원

  Thick-provisioned LVM 스토리지에 새로운 속성이 추가되어 볼륨 체인 방식의 스냅샷을 지원합니다.

  이 설정이 적용되면 VM 스냅샷을 생성할 때 현재 가상 디스크 상태가 스냅샷 이름으로 유지되고, 스냅샷을 기반으로 새로운 볼륨이 시작됩니다.

  이를 통해 iSCSI/파이버 채널을 통해 스토리지 박스에서 제공하는 LUN에 자주 사용되는 공유 Thick-provisioned LVM 스토리지에서도 VM 스냅샷을 생성할 수 있게 됩니다.