Virtualizáció

zslaszlo@zslaszlo-latitude:~$ lxc image import 553330218fb68358699f7b7f7058b3d6d8eb4b788f83c00ac807eb01ad65eb3c.tar.gz --alias koha
Image imported with fingerprint: 553330218fb68358699f7b7f7058b3d6d8eb4b788f83c00
zslaszlo@zslaszlo-latitude:~$ lxc init koha koha
Creating koha
Error: Create LXC container: LXD doesn't have a uid/gid allocation. In this mode, only privileged containers are supported

Mi a hiba?

Sziasztok!

Azért kicsit pipa lesz az ember mikor reggel jelez a telefonja, hogy sorra állnak le az általa üzemeltetett weboldalak és a partnerek hamarosan csörögni fognak.
Persze alapvetően nem olyan nagy gond, mert előfordul az ilyen, de ha úgy történik, hogy volt korábban már egy fél napos leállás és most ez is annyinak néz ki, akkor már igen is gond.
Főleg hogy a partnereim közül van olyan akinek ez, a napi forgalma alapján, több százezer Ft bevétel kiesést jelent. A másik meg várná a fontos leveleit.
Amit most még nem tudok, hogy a szerződésben foglalt éves rendelkezésre állásba ez még belefér-e.

- De ilyen esetben mit tehetek? Főleg ha a partner nekem sem akar fizetni?
- Van olyan szolgáltató, aki legalább az adott havi díjat elengedi?
- Vagy ügyvédet kell fogadnom és beperelni? Vagy anyázni telefonon?
- És a nagy kérdés, amire a valós választ nem kapom meg, hogy mi történt? Miért történt?
- Ki vagy mi a felelős? Valaki nem figyelt? Nincs csere hálózati eszköz vagy vas?

A szolgáltató nevét egyelőre nem írom meg, mert 12 éve náluk vagyok, de ha idén még 1 ilyen van, akkor már nagyon pipa leszek. ( ･ั﹏･ั)

/ és még a szülinapom is ma van, nem viccelek :) /

Üdv!

Van egy kis szerver, amin fut több virtuális gép (Fc31). A gép NIC bridgelt-ként van beállítva és minden lxc konténer hál.interfésze ehhez van kötve. Így a fizikai és az lxc konténerek egy NIC-en érhetők el. Szépen megy is évek óta. Pl.:

hoszt: 10.10.10.201

lxc1: 10.10.10.202

lxc2: 10.10.10.203  ...stb.

Helyi hálózatban van a gép, csak itt használjuk. De most átmenetileg az egyik lxc-t ki kellene tenni a netre (a többi nem is érdekes most). Van publikus IP címünk. Elég csak az adott vm-nek (pl. lxc2) átállítani az IP címét a publikusra? A virtualizáció miatt nem keveredik semmi elvileg...(?)

(Egy másik fizikai szerver működik is egy másik publikus IP címmel. Emellé kellene ez átmenetileg.)

Eddig (mai tapasztalatom alapján: szerencsémre) elkerült a Xen virtualizáció. Pláne a csak parancssoros kivitele. De megörököltem egy régi, Debian 8-ra telepített Xen 4.4 szervert (amire semmi fancy GUI nincs téve, csak egy virsh), amit sajna a rajta futó egy szem VM miatt nem alakíthatok át semmi másra (a VM egy hülye SW licenc dolog miatt nem mozgatható másik gépre, sem azonos gépen nem fut másik hypervisor alatt), ami nekem jobban kézre áll. Mivel pár VM-et át kellene hoznom ennél még régebbi gépekről, nekiláttam utána olvasni ennek a rendszernek, mert a gépban bőven van még szabad erőforrás. Eléggé csalódott vagyok, mert a Xen (régi, open source verzió) rendszerek dokumentációja/fórumos válaszai nagyságrandekkel rosszabbnak/kevesebbnek tűnik nekem, mint bármi más virtualizációnak, amit eddig használtam. Nem találok meg Google-lel alapvető dolgokat csak sokadik keresésre, vagy akkor sem.

Nyilván béna vagyok, de a VM konfig módosítás módját 2 óra volt kinyomoznom, miközben anno a Proxmox-al kezdéskor 2 perc, ESXi-nél meg ugye csak szét kellett nézni a felületen, de még Hyper-V Core-nál sem volt 10 percnél több a PS utasítások megtalálása.

No, ilyen meg nem található dolog számomra a Windows VM-be telepítendő driver csomag is. Hosszas keresés után találtam egy csokor tar állományt, amiben mindeben van egy telepítő, ami egy-egy driver-t tenne fel. De: 1) nem aláírt egyik sem, így hisztizik a Windows 2) semmi leírást nem találok, hogy milyen sorrendben kell őket telepíteni, melyikre van szükségem és melyikre nincs. Ráadásul Windows 2016 STD ment fel egy új VM-be, ilyen verziót még említés szintjén sem mondanak, Win2012-nél, Win10-nél megállnak a témák.

Egyébként alapjában véve működik a VM, de csapni való a teljesítménye, meg kicsit hátrahőköltem, mikor megláttam, hogy egy Realtek 100 Mbites LAN kártyát lát.

Ebben tudna valaki segíteni, merre induljak? Egy jó doksi link is megsegítene (olyan, ami adminoknak, nem fejlesztőknek szól).

No, és ha akadna Xen szakértő, akkor erre tud-e válaszolni: az működhet-e valahogy, hogy egy még régebbi, Debian 6-on futó 4.0.1-es Xen-ről paravirtualizált (Xen kerneles) Linux VM-eket át tudok-e valahogy hozni erre az újabb 4.4-es verzióra a VM-ek komolyabb vegzálása nélkül (ez a cseréljek kernelt nem-PV-re, majd vigyem át HVM-ként nem annyira átlátható számomra)? Ja, a PV VM-ek is ősrégi OS-eket futtatnak (Centos 5-6 meg Debian 5-6). Sajna olyan rendszereket örököltem, amit a telepítés után nem igazán frissítettek "ami működik ahhoz ne nyúljunk" alapon. A Windows HVM-eket simát átmozgattam már régebben ESXi-re, azok működnek gond nélkül szerencsére.
Amit lehet inkább újratelepítek friss alapokra és migrálom az adatokat, de sajna vannak VM-ek, amiknél ez nem működik különböző okokból.

Sziasztok!

Van egy régi weboldalam, CentOS 6 és php 5.3 alatt remekül működik. Mivel hamarosan eljár az OS felett az idő, gondoltam időben elkezdem a migrációt. Csináltam egy teszt szervert CentOS 7-el, a rajta lévő php 5.4-el viszont nem megy a weboldal. Találtam 5.3-as repót, azzal frankó minden.

(amikor nekifutottam, még nem volt CentOS 8, miután kijött azzal is megnéztem, a sokkal frissebb php verzió nem nekem kedvez, de a CentOS 8 lesz a host, azon futnának a konténereim)

Csináltam egy dockerfájlt, amibe pontosan ugyanazokat a lépéseket vettem fel, mint a teszt szerveren, első ránézésre minden klappol, de ha bármilyen módosítást csinálok a konténerben futó weboldalon, akkor egy semmit mondó hibaüzenetet kapok, és a módosítás nem történik meg, mintha az oldal read-only módban működik, miközben az adatbázis írható.

Ez van a dockerfile-ban:

FROM centos:7

COPY src/php-53.repo /etc/yum.repos.d/php-53.repo

RUN yum update -y
RUN yum install -y httpd yum-plugin-versionlock

COPY src/versionlock.list /etc/yum/pluginconf.d/versionlock.list

RUN yum install -y php php-bcmath php-cli php-common php-gd php-intl php-mbstring php-mysql php-pdo php-process php-xml

RUN yum clean all && rm -rf /var/cache/yum/x86_64/7/*

COPY src/php.ini /etc/php.ini
COPY src/httpd.conf /etc/httpd/conf/httpd.conf

EXPOSE 80

CMD ["/usr/sbin/httpd", "-D", "FOREGROUND"]

Így futtatom a konténert:

docker run -d -p 8080:80 --name kontenerem -v /srv/weboldal:/var/www/html kontener:latest

A konténer logokban konkrétan nincs semmi. Kipróbáltam legalább 15-20 php és apache konténert a docker hubról, egyik sem vált be, a legtöbb rosszabb volt, mint a sajátom.

Én még kezdő vagyok a docker világában, pár hete kezdtem el vele foglalkozni, szóval örömmel veszek minden tanácsot, segítséget! Köszönöm!

______________________________________________________________________________

Ezt kellett beszúrnom a megoldáshoz az apache reverse proxyn: ProxyPreserveHost On

Sziasztok,

a fenti gepet vettem es az alabbi OS-ek fognak rajta futni:

-linux szerver (ubuntu)

- 2*win2019 szerver

- 3*win10 kliens

- plusz egyeb gyakorlos, jatszadozos gep (vegyesen windows, linux, bsd)

arra gondoltam, hogy egy vmware exsi 6.5 lenne az alap (tamogatja a dl380p g8-at) es abban hoznek letre VM-eket

valakinek van esetleg mas otlete?

koszi

Gergo

Sziasztok!

Azon filózok, hogy el merjem-e követni a $subject-beli merényletet, vagy sem? Ki kellene cserélni egy öreg, Windows 2008R2-es DC-t és az egyik forgatókönyv az, hogy egy 5.5-ös hostra felrakok egy 2016-ot, ami végül átveszi a szerepét (féltartósan).

Elkezdtem utána guglizni, végül is mire számíthatok. Azt írja a Vmware a KB-ben:

Select Windows Server 2012 as the guest operating system for the virtual machine, if Windows Server 2016 is unavailable.

Note: Windows Server 2016 is compatible with ESXi 5.5 and later, hardware version 10 or later is recommended.

Máshol viszont ennek ellentétes infók vannak, vastaggal szedve, hogy not supported.

Mi a véleményetek? Nyugodjak le, minden szép lesz és menni fog? (Saccra 2-3 évet kellene kibírnia ebben az állapotban).

Sziasztok!

A címbeli témában elkövettem egy kisebb hibát és most nem igazán tudom hogyan tudnám helyrehozni.

A szerverekben lévő hdd-k egy részét lecserélném ssd-re, amihez gondoltam létrehozok egy új poolt, amit meg is csináltam a webes felületen és itt jönnek a problémák. Az új poolt nevezzük SSD-nek ugyan azzal a crush rule id-val hozta létre mint a meglévő HDD-t, a pg számokat szépen össze is adta és ha ssd-t adok hozzá az osd-khez akkor azt a HDD poolba teszi bele. Az SSD poolt nem merem törölni, mert a törléshez kell az ID is ami egyezik a HDD-ével. Kérdésem az lenne, hogy helyre tudom e ezt hozni, illetve, hogy tudok egy egy szerveren egyszerre több poolt is használni?

Sziasztok!

Próbálok egy teljes disket oda adni egyik vm-nek. https://kb.vmware.com/s/article/1017530 ez alapján megcsináltam a lépéseket, minden jó, de mikor megpróbálom hozáadni a vm-hez, akkor: Incompatible device backing specified for device '0'

A datastore két darab 1TB-os SAS HDD-n van, RAID 1-ben.

Hol lehet a probléma?

Sziasztok,

a felallas a kovetkezo:

1x fileszerver + 1x vcenter (5.0.0) + 3x esx (5.0.0) +2x switch + 1x router.

A routeren un VLAN68 alhalozat lett letrehozva, switcheken bekonfiguralva, fileszerveren eth2 hozzaadva es ebbe a VLAN68-ba teve mukodik.

vSphere Client-en keresztul View-->Inventory --> Networking alatt az uj distributed port group hozzaadva.

Egy VM letrehozva (IP,gw,mask) es IP-je ebbol a VLAN68-bol definialva.

Megsem mukodik me'gcsak ping az adott gateway-re sem.

Tudna vki ebben segiteni?

Koszonom.

Ardi