Virtualizáció https://hup.hu/ hu EFI boot KVM guest kernel config https://hup.hu/node/171560 <a href="/taxonomy/term/228" hreflang="hu">Virtualizáció</a> <p>Sziasztok!</p> <p>Egy KVM guestre optimalizált kernel fordításban sikerült elakadni melynek az EFI boot-ot is támogatnia kellene.<br /> Adott a következő kernel config: <a href="https://pastebin.com/1gNMRNmC">https://pastebin.com/1gNMRNmC</a><br /> Megcsináltam a kernel image fájlt illetve az initramfs-t is. Szépen bemásoltam a helyükre mindent majd update-grub és grub-install /dev/sda<br /> A gyári kernel továbbra is bebootol, valamint ki lehet választani a saját kernelt is, de a saját kernellel már nem indul el a rendszer.<br /> Loading Linux 5.9.9-amd64 ...<br /> Loading initial ramdisk ...<br /> ...és itt meg is áll a történet.<br /> Ugyanez a kernel egy nem EFI bootot használó Debian 10-es rendszert simán indít, tehát a nagy valószínűséggel az EFI boot környékén lesz a gond.</p> <p>Mit hagytam még ki a kernel configból?</p> Sat, 21 Nov 2020 13:25:53 +0000 SySERR 171560 at https://hup.hu Docker Desktop (Windows10) images https://hup.hu/node/171528 <a href="/taxonomy/term/228" hreflang="hu">Virtualizáció</a> <p>Üdv!</p> <p>Hova teszi az image-ket Windows10 alatt? Nem találom sehol!</p> <p>A "C:\ProgramData\DockerDesktop" alatt nem.</p> <p> </p> <p>A docker info szerint:</p> <pre> <code> CPUs: 8 Total Memory: 6.089GiB Name: docker-desktop ID: CZ3D:S4LC:VTXS:S44T:BDDK:ZEXX:2OTU:4XYD:WHCW:TGZD:LR3M:3YSP Docker Root Dir: /var/lib/docker </code></pre><p>A /var/lib/docker nem létezik nyilván; a letöltött pl. centos8 image-t nem találom hol van fizikailag.</p> Wed, 18 Nov 2020 22:47:40 +0000 makgab 171528 at https://hup.hu Mire elég 1GB ram? https://hup.hu/node/171445 <a href="/taxonomy/term/228" hreflang="hu">Virtualizáció</a> <p>Sziasztok!</p> <p> </p> <p>Hozzáértők, tapasztaltak véleményét kérdezném (lévén fogalmam sincs ezekről :-( )</p> <p>Remélem, jó kategóriába tettem...:</p> <p>VPS bérlésén gondolkodom, linux alapokon. </p> <p>A feladat(ok):</p> <ul> <li>webes projektek teszt környezete (html only, php, mysql; nem igazán lényeges a performancia; a látogatók száma 5 alatt egy időben)</li> <li>ssh</li> <li>VPN server (csak magamnak)</li> </ul> <p> </p> <p>Ami "megérősnek" tűnik:</p> <ul> <li>1 XEON E5 vCore</li> <li>1 GB RAM</li> <li>20 GB SSD bővíthető 100 GB-ig</li> <li>10Gbps port (2Gbps garantált)</li> </ul> <p>Köszi!</p> Thu, 12 Nov 2020 11:12:11 +0000 duffy 171445 at https://hup.hu QEMU+KVM+ZFS lassú 4k sync IO https://hup.hu/node/171417 <a href="/taxonomy/term/228" hreflang="hu">Virtualizáció</a> <p>Sziasztok,</p> <p>Egy olyan problémába ütköztem, hogy a virtuális gépen belül a 4k random write sync IO kifejezetten lassú.<br /> Ez ott okoz számomra nagyobb problémát, hogy a VM-en belül egy etcd munkálkodna, viszont az kifejezetten nem szereti a lassú fsync-et.</p> <p>A stack (és hozzá minimál leírás):</p> <ul> <li>Fedora CoreOS VM - XFS root</li> <li>QEMU+KVM virtualizáció raw image-el (alapértelmezett cache és io beállítások)</li> <li>CentOS 7 - dom0 - ZFS RAIDZ2 az imagek alatt</li> </ul> <p>ZFS esetén nincs SLOG és L2ARC (előre szólok kezdő ZFS-es vagyok, nem én menedzselem, ami infót hirtelen összetudtam róla gyűjteni és hasznosnak gondoltam, azt írom, de bármilyen plusz információ kell, akkor megpróbálom kinyerni + tanulni mellé :)).</p> <p>Amit próbáltam:</p> <ul> <li>iothread hozzáadása</li> <li>cache writethrough és none beállítások</li> <li>io = native és cache = none beállítás</li> </ul> <p>Sajnos egyik se hozott érdemi változást, így a segítségeteket szeretném kérni, hogy merre lenne érdemes elindulni, mit lenne jó kipróbálni, hogy a sync time lecsökkenjen (az IOPS meg felkusszanjon emiatt, mint kellemes mellékhatás :)), és ne vesszen el annyi valahol a QEMU+Virtio környékén.</p> <p>Néztem fio-val és ioping-el egyaránt.<br /> A használt ioping parancs, és hozzá kimenet:</p> <pre> <code class="language-bash">ioping -i 0 -w 3 -W -Y . dom0: # ioping -i 0 -q -w 3 -W -Y . --- . (zfs storage/) ioping statistics --- 160.8 k requests completed in 2.70 s, 628.0 MiB written, 59.5 k iops, 232.3 MiB/s generated 160.8 k requests in 3.02 s, 628.0 MiB, 53.3 k iops, 208.2 MiB/s min/avg/max/mdev = 6.38 us / 16.8 us / 91.8 ms / 507.8 us VM: # ioping -q -i 0 -w 3 -W -Y . --- . (xfs /dev/vda4 19.5 GiB) ioping statistics --- 45 requests completed in 3.50 s, 180 KiB written, 12 iops, 51.4 KiB/s generated 46 requests in 3.52 s, 184 KiB, 13 iops, 52.2 KiB/s min/avg/max/mdev = 17.0 ms / 77.8 ms / 728.5 ms / 158.4 ms</code></pre> Mon, 09 Nov 2020 22:03:25 +0000 mecseid 171417 at https://hup.hu Docker Hub elérhetősége hosszú távon https://hup.hu/node/171406 <a href="/taxonomy/term/228" hreflang="hu">Virtualizáció</a> <p>Sziasztok,</p> <p>Csak most kezdtem el a dockerrel mélyebben foglalkozni és felmerült egy (pár) kérdés:</p> <p>A Docker Hub-on elérhető alap image-ek meddig elérhetőek?<br /> Úgy értem, hogy teljesen jó, ha most működik letöltöm használom, de mi van akkor, ha egyszercsak a tulajdonosa azt mondja, hogy hmm ezt innentől levesszük.<br /> És ezt nem is veszem észre addig, míg nem frissítem vagy nem akarom újra lehúzni az alap image-et.<br /> Lehet ezt valamilyen formában saját helyre menteni?<br /> Lehet, hogy kcisit paranoiás a kérdés, és ez eddig nem fordult elő nagyon máshol (népszerű szoftverekkel: linux csomagtárolók, github kódok, stb.), de igyekszem felkészülni (legalább elméletben) arra az esetre, ha bekövetkezik.</p> <p>üdv: redman<br />  </p> Mon, 09 Nov 2020 09:10:04 +0000 redman 171406 at https://hup.hu Virtualizációnál hogyan alakítsam ki a partíciókat? https://hup.hu/node/171368 <a href="/taxonomy/term/228" hreflang="hu">Virtualizáció</a> <p>Eredetileg az itthoni szerverre az lett volna, hogy van 2 SSD és 2 HDD, mindegyiken 1-1 ZFS partíció mirrorban, plusz az egyik SSD-n egy EFI partíció a boot loadernek. Az OS FreeBSD vagy OpenBSD. Ez így elég egyszerű kialakítás, viszont most megkavartam azzal, hogy külön router vétele helyett inkább szerveren próbálgatnám, hogy a pfsense vagy egy OpenBSD+PF hogyan fekszik nekem. Ehhez azt mondták, hogy érdemes virtuális gépet feltenni, mert különben biztonsági és erőforrás elosztás szempontjából nem lenne igazi a dolog, ha egy OS-en menne a routing és az alkalmazások futtatása is. Nem tudom ez mennyire igaz, de ha már ez az elfogadott, akkor úgy döntöttem, hogy adok neki egy esélyt. A kérdés az, hogy ez hogyan változtatja meg nálam a fenti partíciókat. Tegyek hozzá valami extrát? Esetleg iktassak be még egy SSD-t a rendszerbe. Amire ténylegesen nekem kell mirror az csak az alkalmazások és a hozzájuk tartozó adatbázisok, fájlok. A router és host OS esetében tökmindegy nekem, hogy milyen a fájlrendszer és hogy van e bitrot. Úgy hallottam, hogy a ZFS és a virtuális fájlrendszerek nem igazán mennek együtt. Tudtok esetleg valami támpontot adni?</p> Fri, 06 Nov 2020 11:44:28 +0000 inf3rno 171368 at https://hup.hu Virtualbox bluetooth https://hup.hu/node/171343 <a href="/taxonomy/term/228" hreflang="hu">Virtualizáció</a> <p>A host LinuxMint egy dell Latitude E7240 laptopon integrált bt modullal. Virtuális gépben egy Manjaro Kde fut. Szeretném tesztelni a kde connect alkalmazást, de sajnos a manjaro nem lát bt adaptert. Hogyan lehetséges a guest oprendszeren megjeleníteni a host bt csatolóját?</p> Thu, 05 Nov 2020 10:13:36 +0000 zslaszlo 171343 at https://hup.hu Scaleway STARDUST1-S VPS https://hup.hu/node/171313 <a href="/taxonomy/term/228" hreflang="hu">Virtualizáció</a> <p>Hátha valakit érdekel:  <a href="https://blog.scaleway.com/a-star-is-born-as-scaleway-launches-stardust-the-worlds-most-cost-effective-cloud-instance/">https://blog.scaleway.com/a-star-is-born-as-scaleway-launches-stardust-the-worlds-most-cost-effective-cloud-instance/</a></p> <p>1 vCPU, 1 GByte memória, 10 GByte storage, 1 IPv4 cím: 0.0025 euro / óra.</p> <p>Csak IPv6 címmel: 0.0005 euro / óra.</p> Mon, 02 Nov 2020 19:07:32 +0000 efel 171313 at https://hup.hu Sophos XG virtualizálva megbízhatatlan https://hup.hu/node/171297 <a href="/taxonomy/term/228" hreflang="hu">Virtualizáció</a> <p>Sziasztok!</p> <p>Több kérdésem is van:</p> <p>1: Sagemcom fast5655v2 modem van a Sophos előtt és van vezetékes telefonra is előfizetés. Virtualizációtól függetlenül a vezetékes telefon nem hajlandó működni amint rákötöm a sophost, szakadozik és nem kapcsol semerre, Bejövő hívás van de az is szakadozik. Kábelezést átnéztem,komplett hardvert cseréltem alatta de semmi változás.</p> <p>2. Ha virtualizálva van a router akkor random eldobja a modemmel a pppoe-t és nem csatlakozik vissza csak miután fizikailag kihúzom a modemből a kábelt és visszadugom<br /> (Volt még egy olyan hiba is hogy a LAN felé néző interfész teljesen összefosta magát és a belső hálózat totál meghalt semmit nem lehetett elérni ha kihúztam a LAN odali kábelt utána minden elérhető volt majd miután visszadugtam működött rendesen majd egy olyan másfél óra múlva megint ugyanez. Ezt a hibát egy hálókártya driver frissítés megoldotta)</p> <p>VMware ESxi 6.7 <span><span>14320388 van a vason.</span></span></p> <p>Ha a Sophos direktben van a vason akkor a 2. pontból semmi nincs.</p> <p> Log-ban ezt találtam:</p> <p>Nov  1 10:54:43 (none) daemon.err pppd[9175]: PortA: Unable to complete PPPoE Discovery<br /> Nov  1 10:54:43 (none) daemon.info pppd[9175]: PortA: Exit.<br /> Nov  1 10:54:43 (none) daemon.warn pppd[9317]: : ip_choose_hook is NULL<br /> Nov  1 10:54:43 (none) daemon.info pppd[9317]: : Plugin /lib/rp-pppoe.so loaded.<br /> Nov  1 10:54:43 (none) daemon.info pppd[9317]: : RP-PPPoE plugin version 3.8p compiled against pppd 2.4.7<br /> Nov  1 10:54:43 (none) daemon.notice pppd[9317]: PortA: pppd 2.4.7 started by root, uid 0<br /> Nov  1 10:54:43 (none) daemon.err pppd[9317]: PortA: Interface PortA has MTU of 1492 -- should be at least 1500.<br /> Nov  1 10:54:43 (none) daemon.err pppd[9317]: PortA: This may cause serious connection problems.<br /> Nov  1 10:55:43 (none) daemon.warn pppd[9317]: PortA: Timeout waiting for PADO packets</p> <p> <span><span>Bárkinek ötlet,tapasztalat?</span></span></p> <p>Köszönöm</p> Sun, 01 Nov 2020 10:22:50 +0000 bocinet1000 171297 at https://hup.hu Vagrant libvirt image magyarázat https://hup.hu/node/170870 <a href="/taxonomy/term/228" hreflang="hu">Virtualizáció</a> <p>Üdv!</p> <p>Kipróbáltam a vagrant-ot libvirt providerrel.</p> <p>A doksiban nem találtam (bár lehet hogy csak átsiklottam felette), hogy az image-ket miért tárolja több helyen?</p> <p>Pl.:</p> <p>~/vagrant  &lt;-- ez a vagrant könyvtár (készítettem egy Vagrantfile-t). Kipróbáltan egy generic/centos8 libvirt (kvm) virtuális környezetet, szépen működik.<br /> A vagrant környezet (fc32):</p> <pre> <code class="language-bash">~/.vagrant.d/boxes/generic-VAGRANTSLASH-centos8/3.0.32/libvirt könyvtár tartalma: box.img 1166MB box_update_check info.json metadata.json Vagrantfile ~/.local/share/libvirt/images generic-VAGRANTSLASH-centos8_vagrant_box_image_3.0.32.img 1166MB vagrant_default.img 785664KB </code></pre><p>Kétszer van a lemezen az image (1166MB), sha256sum ellenőrző összegük ugyanaz és 1-1 hardlinkjük van. Tehát két különböző fájl. A vagrant_default.img dátuma frissül menet közben, tehát ide dolgozik. (Vagy csak a változásokat írja ide?)</p> <p>Régebben használtam kvm/libvirt-et (pl. virt-manager), de akkor minden egy könyvtárban volt és az .img-be mentett mindent.</p> <p>Ez akkor vagrant specialitás v. csak én maradtam le? :)</p> <p> </p> <p>Illetve mi a különbség, ha egy vagrant könyvtárba (Vagrantfile) hozok létre 2 VM-et, mint amikor két külön vagrant könyvtárba (két külön Vagrantfile)?</p> Thu, 24 Sep 2020 17:54:43 +0000 makgab 170870 at https://hup.hu Proxmox ceph nem azonos hardware https://hup.hu/node/170790 <a href="/taxonomy/term/228" hreflang="hu">Virtualizáció</a> <p>Sziasztok! </p> <p>Az volna a kérdésem, hogy 4 szerveres környezetbe a proxmox ceph HA működhet abban az esetben, hogyha a szerverek nem egyformák? CPU memória mindegyik szerverben elég. Esetleg HDD sebességbe van egy kevés eltérés RAID vezérlő miatt. R720, R520, 2db T110</p> <p>A 10G kapcsolat mindegyik szerver között adott.</p> Thu, 17 Sep 2020 17:10:41 +0000 orkenyi 170790 at https://hup.hu [Megoldva] Windows szerver 2016 diszk méret https://hup.hu/node/170787 <a href="/taxonomy/term/228" hreflang="hu">Virtualizáció</a> <p>Van egy fenti szerverem KVM virtualizáció felett. Az egyik diszken elfogyóban a hely - sebaj, megnöveltem az alatta levő LV méretét (mivel DRBD-n van annak a méretét is). Linux alól (pl fdisk-el de bármi mással is) megnézve a DRBD device mérete nagyobb. Ez a device van megadva a virsh-val a virtuális gépnek. Windows alól viszont az eredeti kisebb méret látszik, tehát nem tudom megnövelni a volume-ot. A diszk driver virtio.</p> <p>A rejtély az, hogy csináltam egy ugyanolyan win10 virztuális gépet és ott ezt eljátszva szépen nagyobbnak látja a diszket a windows.</p> <p>Újraindítás nem segít. Van valamilyen trükk amivel rávehetem, hogy nézze meg a diszk méretét egy kicsit alaposabban?</p> <p>Kínomban már arra is gondoltam, hogy linuxos eszközzel megnövelem a GPT partíció méretét, de kissé tartok attól, hogy beal a windows egy olyan partíciótól, ami nagyobb mint szerinte a diszk.</p> Thu, 17 Sep 2020 12:22:17 +0000 MGy 170787 at https://hup.hu Virtualbox Linux iso-k crc hiba + fagyások https://hup.hu/node/170786 <a href="/taxonomy/term/228" hreflang="hu">Virtualizáció</a> <p>Sziasztok!</p> <p>3 teljesen más gépen Windows10-en az a jelenség, hogy telepítés közben (Ubuntu, Mint, Manjaro) elhasal fagyással a linuxos telepítő, vagy ha véletlenül felkúszik az OS, akkor random fagyások vannak, miközben nagyon lassan működnek.<br /> A telepítő iso-k Linuxos boot után eleve CRC hibát jeleznek, ám az iso-k külső ellenőrzéskor jónak találtattak.<br /> Több VirtualBox verzióval is ez a hiba, a fél világ lázongana, ezért én nem állítok be valamit, az az érzésem.<br /> Van tippetek, mit felejtek el?</p> <p>Előre is köszönöm.</p> Thu, 17 Sep 2020 11:55:37 +0000 pepo 170786 at https://hup.hu Proxmox: fizikai hw független VM beállítás https://hup.hu/node/170783 <a href="/taxonomy/term/228" hreflang="hu">Virtualizáció</a> <p>Sziasztok</p> <p>Adott egy windowsos licenszelt program, ami alatt a vas sokat változott már, mindig új licenszet kellett igényelni.</p> <p>Ezt megelégelve, virtualizálni szeretnénk és proxmoxra esett a választás.</p> <p>Abban szeretném a segítségeteket kérni, hogy mi az az elégséges beállítás, amivel nem változnak a windows által látott hw id-k, ha az alatta lévő fizikai vas cserére kerül illetve a proxmox frissül?</p> <p>Addig megvan, hogy a CPU KVM64 legyen.</p> <p>Felmerült, hogy engedjem el a virtio drivereket, mert noha QEMU-t ír mindenhol, de átadhat fizikai hw specifikus azonosítókat?</p> <p>És legyen helyette intel1000 hálókártya, valami LSI vezérlő, stb? Vagy ez felesleges, mert a virtioval ugyanúgy állandó QEMU hw-t mutat mindig, mint egy behazudott intel1000 hálókártya esetében?</p> <p>Annyit lehet sejteni, hogy a licensz a következőkből mixel egy nagy hw id-t: cpu, hálókártya, alaplap(?) hw id, windows nyelvi beállítások. Ami ha változik, ugrott a licensz. HDD cserére viszont nem problémázik.</p> Thu, 17 Sep 2020 10:43:54 +0000 Proci85 170783 at https://hup.hu Virtualbox frissítés 6.12 -> 6.14 ExtensionPack hiba elhárítása (MEGOLDVA) https://hup.hu/node/170650 <a href="/taxonomy/term/228" hreflang="hu">Virtualizáció</a> <p>A frissítés után grafikus felületen sikertelen az EP telepítése a logban ilyesmit lehet találni:</p> <p>Failed to load R0 module /usr/lib/virtualbox/ExtensionPacks/Oracle_VM_VirtualBox_Extension_Pack/linux.amd64/VBoxEhciR0.r0: RTLdrGetBits failed</p> <p> </p> <p>A megoldás innen:</p> <p><a href="https://bbs.archlinux.org/viewtopic.php?id=258118">https://bbs.archlinux.org/viewtopic.php?id=258118</a></p> <p>sudo VBoxManage extpack install --replace ~/Ahovaletöltötted/azextpack-et</p> Sun, 06 Sep 2020 05:02:19 +0000 Ebcsont 170650 at https://hup.hu