Nie jesteś zalogowany.
Jeśli nie posiadasz konta, zarejestruj je już teraz! Pozwoli Ci ono w pełni korzystać z naszego serwisu. Spamerom dziękujemy!

Ogłoszenie

Prosimy o pomoc dla małej Julki — przekaż 1% podatku na Fundacji Dzieciom zdazyć z Pomocą.
Więcej informacji na dug.net.pl/pomagamy/.

Strony: 1

 

#1  2022-02-03 14:53:19

  fnsq - Użytkownik

fnsq
Użytkownik
Zarejestrowany: 2022-02-03

QEMU-KVM Read-only file system po reboocie

Cześć,
na Debianie 9 mam wirtualizację oparta o libvirta/QEMU-KVM. Po problemach z prądem maszyna po prostu się wyłączyła. Po ponownym jej włączeniu zniknęły mi wszystkie wirtualki, które miałem (nie wystartowały nawet z autostartu), a gdy próbuję odpalić je z palca, to wyskakuje mi błąd jak poniżej:

Kod:

error: internal error: process exited while connecting to monitor: 2022-02-03T12:01:58.403986Z qemu-system-x86_64: -drive file=/dev/drbd6,format=raw,if=none,id=drive-virtio-disk0,cache=none: Could not open '/dev/drbd6': Read-only file system

Na fdisku widzę tylko to:

Kod:

Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00037a37

Device     Boot    Start        End    Sectors  Size Id Type
/dev/sda1  *        2048   19531775   19529728  9.3G fd Linux raid autodetect
/dev/sda2       19531776   35155967   15624192  7.5G fd Linux raid autodetect
/dev/sda3       35155968 1939451903 1904295936  908G fd Linux raid autodetect


Disk /dev/sdb: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x000e1911

Device     Boot    Start        End    Sectors  Size Id Type
/dev/sdb1  *        2048   19531775   19529728  9.3G fd Linux raid autodetect
/dev/sdb2       19531776   35155967   15624192  7.5G fd Linux raid autodetect
/dev/sdb3       35155968 1939451903 1904295936  908G fd Linux raid autodetect


Disk /dev/md0: 9.3 GiB, 9998098432 bytes, 19527536 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/md1: 7.5 GiB, 7998525440 bytes, 15622120 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/md2: 908 GiB, 974998331392 bytes, 1904293616 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Jakieś propozycję co mogę jeszcze sprawdzić? Próbowałem zrobić fsck, ale w żaden sposób nie mogę tych dysków odmontować. Na SMARCIE wszystko wygląda OK.

Obrazy tych VM'ek powinienem mieć w /var/lib/libvirt/images, ale ich tam nie ma...

Offline

 

#2  2022-02-03 16:08:01

  fnmirk - Redaktor

fnmirk
Redaktor
Zarejestrowany: 2008-02-19

Re: QEMU-KVM Read-only file system po reboocie

A gdzie kopia zapasowa? Nie wiem, czy po tym jak zacząłeś ostro traktować system to coś uratujesz?

System po awarii zasilania, najlepiej sprawdzać z poziomu zewnętrznego systemu.

Offline

 

#3  2022-02-03 19:54:23

  fnsq - Użytkownik

fnsq
Użytkownik
Zarejestrowany: 2022-02-03

Re: QEMU-KVM Read-only file system po reboocie

fnmirk napisał(-a):

A gdzie kopia zapasowa? Nie wiem, czy po tym jak zacząłeś ostro traktować system to coś uratujesz?

System po awarii zasilania, najlepiej sprawdzać z poziomu zewnętrznego systemu.

Cześć, dzięki za odpowiedź. Mówiąc o ostrym traktowaniu masz na myśli próby odmontowania dysków?

To na pewno, lecz serwer ten fizycznie nie znajduje się w Polsce. Raczej chciałem sie zapytać czy jest jakaś możliwość odzyskania tych gotowych obrazów i nie robienia tego w taki sposób, że stawiam wszystko od nowa i przywracam potrzebne bazy, apki itp. z backupów. Wszędzie korzystam z Proxmoxa i nie miałem nigdy nie miałem z nim takiej akcji jak w tym przypadku (nawet przy takich awariach zasilania jak ta).

Offline

 

#4  2022-02-03 20:31:29

  mati75 - Psuj

mati75
Psuj
Skąd: masz ten towar?
Zarejestrowany: 2010-03-14

Re: QEMU-KVM Read-only file system po reboocie

Według danych z fdisk brakuje jednej partycji z mdadm. Pokaże to :

Kod:

cat /proc/mdstat

Błąd wskazuje na to że trzeba wykonać fsck na partycji.

https://l0calh0st.pl/obrazki/userbar.png

Offline

 

#5  2022-02-03 21:44:06

  fnsq - Użytkownik

fnsq
Użytkownik
Zarejestrowany: 2022-02-03

Re: QEMU-KVM Read-only file system po reboocie

mati75 napisał(-a):

Według danych z fdisk brakuje jednej partycji z mdadm. Pokaże to :

Kod:

cat /proc/mdstat

Błąd wskazuje na to że trzeba wykonać fsck na partycji.

RAID jest hardware'owy, a nie software'owy.

Offline

 

#6  2022-02-04 11:37:32

  mati75 - Psuj

mati75
Psuj
Skąd: masz ten towar?
Zarejestrowany: 2010-03-14

Re: QEMU-KVM Read-only file system po reboocie

Jaki hardware?

Kod:

Disk /dev/md0: 9.3 GiB, 9998098432 bytes, 19527536 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/md1: 7.5 GiB, 7998525440 bytes, 15622120 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/md2: 908 GiB, 974998331392 bytes, 1904293616 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

To jest softraid. Hardware raid jest widoczny jako po prostu 2 dyski.

Widzę że nie przeskrolowałem niżej, puściłbym fsck na /dev/md2

Ostatnio edytowany przez mati75 (2022-02-05 13:01:44)

https://l0calh0st.pl/obrazki/userbar.png

Offline

 

#7  2022-02-05 09:33:50

  fnmirk - Redaktor

fnmirk
Redaktor
Zarejestrowany: 2008-02-19

Re: QEMU-KVM Read-only file system po reboocie

Spróbuj skorzystać z:
https://www.system-rescue.org/Download/
Ale może być potrzebny ktoś „załapany”, kto uruchomi drugi system fizycznie na serwerze.

Przejrzyj dokumentacje do system-rescue, może znajdziesz jakiś inny pomysł.

Offline

 

#8  2022-02-08 11:58:10

  fnsq - Użytkownik

fnsq
Użytkownik
Zarejestrowany: 2022-02-03

Re: QEMU-KVM Read-only file system po reboocie

Jak się okazało problem leży raczej po stronie drbd (dodatkowo jest jeszcze zainstalowany i skonfigurowany corosync). Nie miałem pojęcia, że tak to jest tutaj rozwiązane i przeczesuję sobie internet w poszukiwaniu podobnego problemu. Co udało mi się wywnioskować to (to samo na obu primary i secondary):

Kod:

# service drbd status
● drbd.service - LSB: Control DRBD resources.
   Loaded: loaded (/etc/init.d/drbd; generated; vendor preset: enabled)
   Active: active (exited) since Tue 2022-02-08 11:34:48 CET; 6min ago
     Docs: man:systemd-sysv-generator(8)
  Process: 12711 ExecStop=/etc/init.d/drbd stop (code=exited, status=0/SUCCESS)
  Process: 12793 ExecStart=/etc/init.d/drbd start (code=exited, status=0/SUCCESS)

Feb 08 11:34:47 brain systemd[1]: Starting LSB: Control DRBD resources....
Feb 08 11:34:47 brain drbd[12793]: Starting DRBD resources:[
Feb 08 11:34:47 brain drbd[12793]:      create res: r0 r1 r10 r2 r3 r4 r5 r6 r7 r8 r9
Feb 08 11:34:47 brain drbd[12793]:    prepare disk: r0 r1 r10 r2 r3 r4 r5 r6 r7 r8 r9
Feb 08 11:34:47 brain drbd[12793]:     adjust disk: r0:failed(apply-al:20) r1:failed(apply-al:20) r10:failed(apply-al:20) r2:failed(apply-al:20) r3:failed(apply-al:20) r4:failed(apply-al:20) r5:failed(apply
Feb 08 11:34:47 brain drbd[12793]:      adjust net: r0 r1 r10 r2 r3 r4 r5 r6 r7 r8 r9
Feb 08 11:34:47 brain drbd[12793]: ]
Feb 08 11:34:48 brain drbd[12793]: WARN: stdin/stdout is not a TTY; using /dev/console.
Feb 08 11:34:48 brain systemd[1]: Started LSB: Control DRBD resources..

Kod:

# cat /proc/drbd
version: 8.4.7 (api:1/proto:86-101)
srcversion: F7D2F0C9036CD0E796D5958
 0: cs:Connected ro:Secondary/Secondary ds:Diskless/Diskless C r-----
    ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0
 1: cs:Connected ro:Secondary/Secondary ds:Diskless/Diskless C r-----
    ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0
 2: cs:Connected ro:Secondary/Secondary ds:Diskless/Diskless C r-----
    ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0
 3: cs:Connected ro:Secondary/Secondary ds:Diskless/Diskless C r-----
    ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0
 4: cs:Connected ro:Secondary/Secondary ds:Diskless/Diskless C r-----
    ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0
 5: cs:Connected ro:Secondary/Secondary ds:Diskless/Diskless C r-----
    ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0
 6: cs:Connected ro:Secondary/Secondary ds:Diskless/Diskless C r-----
    ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0
 7: cs:Connected ro:Secondary/Secondary ds:Diskless/Diskless C r-----
    ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0
 8: cs:Connected ro:Secondary/Secondary ds:Diskless/Diskless C r-----
    ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0
 9: cs:Connected ro:Secondary/Secondary ds:Diskless/Diskless C r-----
    ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0
10: cs:Connected ro:Secondary/Secondary ds:Diskless/Diskless C r-----
    ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0

Kod:

# drbdadm primary r0
0: State change failed: (-2) Need access to UpToDate data
Command 'drbdsetup-84 primary 0' terminated with exit code 17

Secondary na drugiej maszynie działa.

Kod:

# drbdadm up r0
open(/dev/vg0/lv-sheep) failed: No such file or directory
Command 'drbdmeta 0 v08 /dev/vg0/lv-sheep internal apply-al' terminated with exit code 20

I faktycznie nie mogę znaleźć /dev/vg0 w ogóle na maszynie. Wszystko leży w /dev/drbd/vg0/by-disk/lv-sheep.

Nie wiem czy jeżeli te VM'ki już istniały powinienem polecieć taką sekwencją komend:

Kod:

# drbdadm create-md r0
# drbdadm up r0
# drbdadm primary r0 --force
# mkfs.ext4 /dev/drbd0

I czy coś to da i czy nie zepsuje wszystkich danych, które tam mam. Jakieś rady/ewentualne potwierdzenie sekwencji komend, którą podałem wyżej?

Offline

 

#9  2022-02-09 09:25:20

  fnsq - Użytkownik

fnsq
Użytkownik
Zarejestrowany: 2022-02-03

Re: QEMU-KVM Read-only file system po reboocie

Podsyłam jeszcze dodatkowe info, który może coś pomóc:

Kod:

# vgdisplay
  --- Volume group ---
  VG Name               vg0
  System ID
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  26
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                11
  Open LV               0
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               908.04 GiB
  PE Size               4.00 MiB
  Total PE              232457
  Alloc PE / Size       177664 / 694.00 GiB
  Free  PE / Size       54793 / 214.04 GiB
  VG UUID               cHjzTE-lZxc-J6Qs-35jD-3kRn-csJx-g5MgNy

Kod:

# cat /etc/drbd.conf
# You can find an example in  /usr/share/doc/drbd.../drbd.conf.example

include "drbd.d/global_common.conf";
include "drbd.d/*.res";

Kod:

# cat /etc/drbd.d/r1.res
resource r1 {
        device          /dev/drbd1;
        disk            /dev/vg0/lv-viewcenter;
        meta-disk       internal;

        startup {
#               become-primary-on both;
        }

        net {
                allow-two-primaries;
                after-sb-0pri discard-zero-changes;
                after-sb-1pri discard-secondary;
                after-sb-2pri disconnect;
                cram-hmac-alg sha1;
                shared-secret "T/L0zE/i9eiPI";
        }

        syncer {
                rate 200M;
        }

        on brain {
                address         10.0.0.1:7789;
        }

        on pinky {
                address         10.0.0.2:7789;
        }
}

Offline

 

#10  2022-02-15 15:23:41

  fnsq - Użytkownik

fnsq
Użytkownik
Zarejestrowany: 2022-02-03

Re: QEMU-KVM Read-only file system po reboocie

Zapomniałem napisać, że problem rozwiązałem. Po komendzie "vgdisplay" coś mnie tknęło i wpisałem komendę "lvdisplay" i to wyświetliło wszystkie moje VM'ki. Następnie poleciałem sekwencją komend jak poniżej:

Kod:

# vgscan --mknodes
File descriptor 8 (pipe:[270576]) leaked on vgscan invocation. Parent PID 15357: bash
Reading volume groups from cache.
Found volume group "vg0" using metadata type lvm2

Kod:

# vgchange -a y
File descriptor 8 (pipe:[270576]) leaked on vgchange invocation. Parent PID 15357: bash
11 logical volume(s) in volume group "vg0" now active

I wszystkie logiczne woluminy z powrotem się pojawiły. Następnie uczyniłem VM'ki jako primary, podniosłem je i odpliłem VM'ki:

Kod:

# drbdadm primary r6
# drbdadm up r6
# virsh start VM

I wszystko zaczęło działać.

Offline

 

 

Strony: 1

Stopka forum

Powered by PunBB
© Copyright 2002–2005 Rickard Andersson
To nie jest tylko forum, to nasza mała ojczyzna ;-)