Ten raport z września 2025 r. należy traktować jako historyczny, specyficzny dla wersji beta błąd ZVM, a nie jako aktualny wniosek, że „ZVM nie działa”. Użytkownik korzystał z ZimaOS 1.4.4-beta1 i wielokrotnie obserwował niepowodzenie uruchamiania maszyn wirtualnych z wewnętrznym komunikatem client socket is closed. Zima-Giorgio przetestował maszynę wirtualną Ubuntu na tej samej wersji beta i stwierdził, że działała normalnie, więc problem nie występował powszechnie we wszystkich instalacjach 1.4.4-beta1.
Najbardziej przydatna część wątku dotyczy zawężania diagnozy. KVM było załadowane, domyślna sieć libvirt i pula magazynu były aktywne, a zresetowanie konfiguracji libvirt nie pomogło. Późniejsze dzienniki pokazały virtqemud nie udało się połączyć z sieciowym gniazdem libvirt, po czym usługa została dezaktywowana.
Ponowne uruchomienie libvirt-guests nie dotyczyło właściwej warstwy
Pierwotny użytkownik najpierw ponownie uruchomił libvirt-guests.service. Uczestnik społeczności zwrócił uwagę, że ta usługa zajmuje się głównie zapisywaniem i przywracaniem stanu gości podczas wyłączania hosta; nie jest podstawowym demonem QEMU/libvirt uruchamiającym maszynę wirtualną.
Pomyślne ponowne uruchomienie tej usługi nie dowodziło zatem, że stos maszyn wirtualnych działa prawidłowo.
Sprzętowe przyspieszenie KVM było dostępne
Użytkownik sprawdził załadowane moduły i stwierdził, że oba kvm oraz kvm_intel. Wykluczyło to jedną z częstych przyczyn: całkowity brak obsługi wirtualizacji na poziomie jądra.
Domyślna sieć i pule magazynu były aktywne
W wątku sprawdzono również domyślną sieć libvirt i pulę magazynu. Obie były aktywne i dostępne.
To zmniejszyło prawdopodobieństwo, że główną przyczyną jest brak magazynu maszyn wirtualnych lub nieaktywna sieć NAT.
Pełne zresetowanie konfiguracji libvirt nie rozwiązało problemu
Pierwotny autor usunął konfigurację z /etc/libvirt oraz /var/lib/libvirt i nadal odtwarzał błąd. Był to destrukcyjny krok diagnostyczny, którego nie należy zalecać jako obecnego rozwiązania pierwszego wyboru.
W nowoczesnym systemie produkcyjnym przed modyfikowaniem stanu libvirt utwórz kopie zapasowe definicji maszyn wirtualnych i obrazów dysków.
Późniejszy dziennik wskazał na virtqemud i gniazdo sieciowe
Użytkownik opublikował następnie bardziej przydatny komunikat o błędzie: virtqemud nie udało się połączyć z gniazdem w /var/run/libvirt/..., po czym usługa została dezaktywowana. Komunikat interfejsu o zamknięciu gniazda klienta był więc prawdopodobnie objawem wtórnym problemu z demonem zaplecza.
Demon wyświetlający komunikat „Zakończono pomyślnie” może mimo to powodować awarie aplikacji
Kilka demonów libvirt jest aktywowanych przez gniazda i może się zatrzymywać w stanie bezczynności, dlatego samo określenie „nieaktywny” nie stanowi dowodu awarii. W tym przypadku jednak wyraźny błąd połączenia z gniazdem oraz logi zakończenia działania maszyny wirtualnej sprawiły, że interakcja z zapleczem budziła podejrzenia.
Interpretuj stan systemd w połączeniu z rzeczywistym błędem libvirt/QEMU, a nie na podstawie pojedynczego wiersza statusu rozpatrywanego w oderwaniu od kontekstu.
IceWhale nie udało się odtworzyć problemu w środowisku testowym
Zima-Giorgio poinformował, że maszyna wirtualna Ubuntu działała normalnie na wersji 1.4.4-beta1, i poprosił o podanie typu systemu operacyjnego oraz zrzutów ekranu lub nagrania wideo. To ważne oficjalne zastrzeżenie: źródło pokazuje rzeczywisty problem użytkownika, ale nie potwierdza awarii dotyczącej całej wersji beta.
Użytkownik zgłosił problem jako błąd wersji beta na GitHubie
Autor przeniósł szczegółowe logi i nagranie wideo do systemu zgłoszeń GitHub firmy IceWhale, ponieważ przesyłanie plików na forum było utrudnione. Załączonym źródłem było nagranie wideo, a nie statyczny zrzut ekranu z forum.
Publiczny wątek na forum nie zawiera informacji o wydaniu ani ostatecznej poprawki wskazującej jedną potwierdzoną przyczynę źródłową.
Nie stosuj ingerencji w usługi z wersji 1.4.4-beta1 do obecnej wersji ZimaOS
Obecna wersja ZimaOS znacznie różni się od tej wersji beta. Pakiety libvirt, interfejs ZVM, obsługa obrazów i działanie usług systemd mogą wyglądać zupełnie inaczej.
W przypadku podobnego bieżącego błędu przed modyfikacją plików systemowych zbierz komunikat błędu maszyny wirtualnej, aktualną wersję ZimaOS, stan KVM, stan sieci i pamięci masowej libvirt oraz logi QEMU.
Błąd zmieniał się wraz z gromadzeniem przez użytkownika lepszych dowodów
Początkowa teoria zakładała po prostu, że wersja beta ZVM zawierała poważniejszy błąd, ponieważ ponowne uruchomienie usługi nie pomogło. Kolejna runda testów wykazała, że KVM było dostępne, a domyślna sieć i pamięć masowa działały prawidłowo. Dopiero wtedy błąd gniazda wewnątrz virtqemud stało się widoczne.
Ta sekwencja stanowi dobry model rozwiązywania problemów z wirtualizacją: unikaj przechodzenia od ogólnego błędu interfejsu bezpośrednio do ponownej instalacji hiperwizora. Eliminuj kolejno warstwy akceleracji sprzętowej, pamięci masowej, sieci i usług.
virtqemud zależy od pozostałych elementów modułowego stosu libvirt
Zarejestrowany błąd dotyczył gniazda sieciowego libvirt. W nowoczesnym modułowym libvirt zarządzanie QEMU, zarządzanie siecią, rejestrowanie dzienników i inne funkcje mogą działać w oddzielnych demonach i korzystać z oddzielnych gniazd. Demon QEMU może więc być obecny, a jednocześnie nie komunikować się z demonem sieciowym, którego potrzebuje.
Pomaga to wyjaśnić, dlaczego maszyna wirtualna mogła ulec awarii, mimo że KVM i pula pamięci masowej wyglądały normalnie.
Dzienniki QEMU pokazały kończenie procesów gości
Dzienniki QEMU użytkownika wielokrotnie pokazywały kończenie procesów gości sygnałem 15 z virtqemudTo wspiera tezę, że goście byli wyłączani przez stos kontroli wirtualizacji, zamiast ulegać awarii z powodu wadliwego obrazu ISO systemu Windows lub Linux.
Użytkownik przetestował również kilka obrazów ISO i zaobserwował to samo zachowanie, co dodatkowo osłabia wyjaśnienie zakładające „uszkodzony nośnik instalacyjny”.
Regresję w wersji beta należy porównać z wersją stabilną przed wykonaniem destrukcyjnych napraw
Użytkownik społeczności zasugerował powrót do kanału stabilnego, jeśli maszyny wirtualne były potrzebne natychmiast. To rozsądny punkt diagnostyczny w przypadku awarii występującej wyłącznie w wersji beta: jeśli ta sama maszyna wirtualna i ten sam sprzęt działają w wersji stabilnej, wersja beta staje się najsilniejszą zmienną, która uległa zmianie.
Wątek źródłowy nie zawiera końcowego potwierdzenia wycofania zmian przez autora oryginalnego wpisu, więc pozostaje to strategią diagnostyczną, a nie zweryfikowaną poprawką w źródle.
W przypadku bieżącej awarii ZVM zachowaj pierwszy błąd zaplecza
Komunikaty interfejsu, takie jak „gniazdo klienta jest zamknięte”, często pojawiają się po istotnym zdarzeniu w zapleczu. Zapisuj dzienniki systemu i QEMU dokładnie w chwili kliknięcia przycisku Uruchom i zachowuj najwcześniejszy błąd, zamiast ograniczać się do końcowego komunikatu o stanie.
Zmniejsza to ryzyko uznania objawu występującego niżej w stosie za przyczynę źródłową.
Historyczne FAQ wersji beta ZVM
Czy w pierwotnym przypadku brakowało KVM?
Nie. Użytkownik potwierdził, że moduły KVM były załadowane.
Czy zresetowanie konfiguracji libvirt rozwiązało problem?
Nie.
Czy problem potwierdzono w każdym systemie z wersją 1.4.4-beta1?
Nie. Zima-Giorgio powiedział, że testowa maszyna wirtualna Ubuntu działała normalnie na tej samej wersji beta.
Jaka była najsilniejsza wskazówka dotycząca zaplecza?
virtqemud odnotowano błąd podczas łączenia z gniazdem sieciowym libvirt przed dezaktywacją.
