Látom megy a főoldaluk és a hup is.
Viszont az ügyfélportáljuk leállt. Valamint a VPS-em is.
Du. már láttam furcsa hálózati forgalom emelkedést. Most is azt láttam mielőtt lehalt.
Átálltam tartalék szerverre.
Sziasztok!
Adott egy cpu érrzékeny licenszelt szoftver, amit virtualizálni fogunk. Cél a későbbi mozgathatóság, ezért rögzített CPU beállítás kell a virtuális gép configjában.
KVM64 vagy QEMU64 a javasolt? Neten nem sok konkrétumot találtam.
Jelenleg E5-2630 v3 CPU van a host gépben. Gondolom a jövőben sem fog ennél rosszabb helyre kerülni. Érdemes lenne esetleg Haswell CPU-t behazudni a VM-nek és azt tartani kvázi örökre?
Köszönöm!
Sziasztok!
Szeretnék segítséget kérni tapasztaltabb zfs hozzáértőktől. Proxmox (6.3) alatt a pve-zsync nevű toolt használom replikációra két host között, amik külön clusterben vannak. Szépen működött is a replikáció. Egyszercsak át kellett állni a replikára, ami ügyesen pár perc alatt meg is történt. Előtte leállítottam a repklikációt is (pve-zsync disable, aztán destroy), minden rendben volt, elindult a replika. Töröltem a felesleges snapshotokat mindkét oldalon (zfs destroy akarmi@snapshot), a host1-en töröltem az eredeti vm-diskeket is, vm-konfigot is. Meggyógyítottam az eredeti hosztot, és gondoltam, elindítom visszafelé a replikációt. Ezt az eredményt kapom:
pve-zsync sync --source 10.0.0.132:1401 --dest unity-zfs-pool --name vm1401 --maxsnap 2 --method ssh --source-user root --dest-user root --verbose --skip
warning: cannot send 'unity-zfs-pool/vm-1401-disk-0@rep_vm1401_2021-05-26_07:47:20': Unknown error 1030
Job --source 10.0.0.132:1401 --name vm1401 got an ERROR!!!
ERROR Message:
COMMAND:
ssh -o 'BatchMode=yes' root@10.0.0.132 -- zfs send -v -- unity-zfs-pool/vm-1401-disk-0@rep_vm1401_2021-05-26_07:47:32 | zfs recv -F -- unity-zfs-pool/vm-1401-disk-0
GET ERROR:
cannot receive: failed to read from stream
Próbáltam egy tetszőleges más snapshotot is zfs send/receive-vel átvinni. Ugyanez a hibaüzenet. Mi ez a hiba, és hogyan lehet megjavítani? Van valakinek ötlete?
Hi!
Fc34 alatt próbálom ismét az LXC-t, de nem lát ki a konténer, IP-t sem kap. (lxc-4.0.6-2.fc34.x86_64)
# Distribution configuration
lxc.include = /usr/share/lxc/config/common.conf
lxc.arch = x86_64
# Container specific configuration
lxc.rootfs.path = dir:/var/lib/lxc/fedora34/rootfs
lxc.uts.name = fedora34
# Network configuration
lxc.net.0.type = veth
lxc.net.0.link = lxcbr0
lxc.net.0.flags = up
lxc.net.0.hwaddr = ......
Elvileg a 10.0.3.0/24 tartományból osztana (lxcbr0)
Ha hozzáadom az IP-t akkor sem lát ki: "...a hálózat elérhetetlen".
lxc.net.0.ipv4.address = 10.0.3.100/24
#lxc.net.0.ipv4.gateway = 10.0.3.1
Mi hiányzik neki? (Egyik konténer/disztrib sem lát ki.)
Az új Proxmox 6.4-nek van két igen jó új funkciója.
Az első, hogy virtual gép PBS mentésekből képes fájl szinten olvasni (konténerből eddig is tudott), azaz egy Windows mentésből helyre lehet állítani egy kattintással egy darab fájlt is, ez nagyon király, nem kell ezért valamilyen más mentést is használni a windows-on.
A másik a Live Restore. Visszaállítás közben elindítható a gép! Ehhez azért kell hálózat és disk io teljesítmény, viszont ha van, elég jó nézni, hogy még megy a restore a gép meg már rég elindult.
Látszik, hogy a Proxmox erősen fejleszti a PBS megoldását, a deduplikálás, Live Restore, File Restore már kezd egy igen ütős párossá összeállni.
https://www.proxmox.com/en/training/video-tutorials/item/what-s-new-in-…
Sziasztok!
Windows 10-et szeretnék telepíteni egy vm-be, de ahelyett, hogy bebootolna az iso-ról, az uefi shellben találom magamat. Kipróbáltam azt, hogy a pxe boot állítom első helyre, hátha előbb túlmegy a billentyűleütés várásán, minthogy mutatná a konzol képét, de azt látom, hogy miután túllép a pxe boot próbálkozáson, azonnal jön az uefi shell.
A dvd boot engedélyezve van természetesen. Megpróbáltam, hogy lecserélem az iso-t, hátha hibás, de a másikkal ugyanezt csinálta.
Sziasztok!
Segítséget kérnék, mert nem jövök rá hol van pontosan a probléma.
Adott egy FUJITSU BX400S1 blade, benne BX920S4 pengék, ezeken CentOS 8(elrepo is kellett a be2net-hez) (volt 7 is ugyan ez a gond, oVirt 4.3) oVirt 4.4(legújabb)
A jelenség, hogy Win2012R2 szerver virtio (de e1000-rel is) lokálisan(hostról) pingetve 20% packett loss-t produkál.
Az látszik, hogy a vnetX interface-en már nem mennek ki a csomagok! (iptables, firewalld, ebtables átnézve, kikapcsolva)
A VPS-ben linux(systemresuecd) is ugyan úgy produkálja a loss-t. (szvsz. nem a guest OS-től függ a probléma)
Googel meg volt, akik hasonlóval találkoztak, ott volt bonding(nállam nincs)
Köszi!
update1: az ovirt-engine felé nincs loss, illetve a windowsból kifelé sincs loss(ping)
update2: a windows gép mac address-e flap-el a ovirtmgmt fizikai és a tap interface között, ilyet még nem láttam
update3: https://users.ovirt.narkive.com/npSQpNy0/ovirt-users-problemas-with-ovi…
update4: megoldás nincs, ovirtmgmt-nek lett külön VLAN, ezzel megoldva
Sziasztok!
Már vagy negyedjére fordul elő fél év alatt és kezd már bosszantó lenni.
Proxmox 6.1, 6.2, 6.3 is megcsinálta, hogy random vagy ma éjjel gép importálása közben egy másik KVM gép ( Debian van rajta ) virtuális lemezéről eltűnt a fájlrendszer. Gparted Live boot után RAW lemez. Adatok rajta vannak, testdisk látja és vissza is tudom állítani. Egy-egy gépen amin előfordult eddig szerencsére nem volt sok cucc, pl. csak levelezés így VPS mentés visszatölt, rsync az előző napi mentésből és kész ( persze egy nap bukta így is ), de így is gáz.
Szóval adott most Proxmox 6.3, teljesen default telepítés. Fut rajta A,B,C VPS és a D VPS importálásakor a C virtuális lemeze megpusztult. A host gépben új lemezek, Dell Perc vezérlő. Kb. 120 Gb-os VPS-t importáltam. De volt olyan eset, hogy éjjel megment, semmi tevékenység nem volt.
Járt így valaki még? Gondolom igen mert 3 különböző fizikai gépen is csinálta már nekem, így esélyes, hogy másnak is. Proxmox-al meg eddig nem volt bajom, 8+ éve használom.
Szeretnék tényleg "IaC" módon megépíteni egy-két dolgot.
Jelenleg ott tartok, hogy portainer-el installálok git repóból docker stacket, ez megy is szépen.
Most azzal szembesültem, hogy ha van egy volume egy service-nek (containernek) ami meg kéne maradjon (perzisztensen) akkor azt hogyan kell "jól" csinálni ?
Ha megcsinálom external volume-ként akkor triviális a dolog, úgy működik ahogy elvárnám, azaz ott marad két deploy között is.
Ott kell legyen előre (ha nincs akkor hibát dob a stack deploy), ha disaster van akkor nekem kell gondoskodni a volume restore-ról, akárhogy.
Ha ez a "normái út" akkor ezt a restore folyamatot hogyan szokás (és mennyire lehet) automatizálni?
Ezt le kell magamnak scriptelni mondjuk egy external backup location-ből visszaszedni mindent?
Van egy vps-em az Arubánál. Eddig sem volt a legstabilabb, de most teljes elérhetetlenség. A "barátságos" kezelőfelület semmi érdemlegeset nem mond, azon kívül, hogy a ping valami free demo sitre ugrik. Amúgy senki sehol sem elérhető.
Másnak is ilyen? Hogy lehet őket nógatni?