Hyper-V diske skifter plads
Hej Forum.
Jeg har en server i vores hosting - som jeg har fået et lille problem med.
Før i tiden kørte de på VM-ware men er skiftet til Hyper-V nu. Vi har en Debian8 Server 64Bits kørende som vi oplever følgende på:
ved rebbot skifter harddiske plads --> sda blir til sdb og modsat.
Så vidt jeg har kigget mig frem til er det under opstarten af Debian hvor der indlæses modsat fra SCSI driveren.
Burde den ikke indlæse scsi0 først og ikke scsi1 og derefter scsi0 ?
Er der andre der har oplevet dette problem på Hyper-V / Debian og har en løsning, ville jeg være rigtig glad. da det sker ca hver 4-5 gang den rebooter (hvilket den gør hver nat grundet backuprutiner)
MVH
P
Jeg har en server i vores hosting - som jeg har fået et lille problem med.
Før i tiden kørte de på VM-ware men er skiftet til Hyper-V nu. Vi har en Debian8 Server 64Bits kørende som vi oplever følgende på:
ved rebbot skifter harddiske plads --> sda blir til sdb og modsat.
Så vidt jeg har kigget mig frem til er det under opstarten af Debian hvor der indlæses modsat fra SCSI driveren.
Dec 14 21:02:12 insa02 kernel: [ 0.543083] scsi1 : storvsc_host_t
Dec 14 21:02:12 insa02 kernel: [ 0.543274] scsi0 : storvsc_host_t
Dec 14 21:02:12 insa02 kernel: [ 0.543310] scsi: waiting for bus probes to complete ...
Dec 14 21:02:12 insa02 kernel: [ 0.543323] scsi 1:0:0:0: Direct-Access Msft Virtual Disk 1.0 PQ: 0 ANSI: 4
Dec 14 21:02:12 insa02 kernel: [ 0.548035] scsi 0:0:0:0: Direct-Access Msft Virtual Disk 1.0 PQ: 0 ANSI: 4
Dec 14 21:02:12 insa02 kernel: [ 0.557643] hv_netvsc: hv_netvsc channel opened successfully
Dec 14 21:02:12 insa02 kernel: [ 0.560129] sd 1:0:0:0: Attached scsi generic sg0 type 0
Dec 14 21:02:12 insa02 kernel: [ 0.560186] sd 0:0:0:0: Attached scsi generic sg1 type 0
Dec 14 21:02:12 insa02 kernel: [ 0.560901] sd 1:0:0:0: [sda] 738197504 512-byte logical blocks: (377 GB/352 GiB)
Dec 14 21:02:12 insa02 kernel: [ 0.560926] sd 1:0:0:0: [sda] Write Protect is off
Dec 14 21:02:12 insa02 kernel: [ 0.560928] sd 1:0:0:0: [sda] Mode Sense: 0f 00 00 00
Dec 14 21:02:12 insa02 kernel: [ 0.560986] sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Dec 14 21:02:12 insa02 kernel: [ 0.566346] sda: sda1
Dec 14 21:02:12 insa02 kernel: [ 0.566648] sd 1:0:0:0: [sda] Attached SCSI disk
Dec 14 21:02:12 insa02 kernel: [ 0.568048] sd 0:0:0:0: [sdb] 482344960 512-byte logical blocks: (246 GB/230 GiB)
Dec 14 21:02:12 insa02 kernel: [ 0.572029] sd 0:0:0:0: [sdb] Write Protect is off
Dec 14 21:02:12 insa02 kernel: [ 0.572031] sd 0:0:0:0: [sdb] Mode Sense: 0f 00 00 00
Dec 14 21:02:12 insa02 kernel: [ 0.577909] sd 0:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Dec 14 21:02:12 insa02 kernel: [ 0.578179] ata_piix 0000:00:07.1: version 2.13
Dec 14 21:02:12 insa02 kernel: [ 0.578336] ata_piix 0000:00:07.1: Hyper-V Virtual Machine detected, ATA device ignore set
Dec 14 21:02:12 insa02 kernel: [ 0.580499] scsi2 : ata_piix
Dec 14 21:02:12 insa02 kernel: [ 0.580654] scsi3 : ata_piix
Dec 14 21:02:12 insa02 kernel: [ 0.580692] ata1: PATA max UDMA/33 cmd 0x1f0 ctl 0x3f6 bmdma 0xffa0 irq 14
Dec 14 21:02:12 insa02 kernel: [ 0.580693] ata2: PATA max UDMA/33 cmd 0x170 ctl 0x376 bmdma 0xffa8 irq 15
Dec 14 21:02:12 insa02 kernel: [ 0.587636] sdb: sdb1 < sdb5 sdb6 > sdb2
Dec 14 21:02:12 insa02 kernel: [ 0.589086] sd 0:0:0:0: [sdb] Attached SCSI disk
Burde den ikke indlæse scsi0 først og ikke scsi1 og derefter scsi0 ?
Er der andre der har oplevet dette problem på Hyper-V / Debian og har en løsning, ville jeg være rigtig glad. da det sker ca hver 4-5 gang den rebooter (hvilket den gør hver nat grundet backuprutiner)
MVH
P
Kommentarer5
Det er længe siden man
UUID=e6d35c81-ce24-4af2-9468-68f2a11a78cc /boot ext2 defaults 0 0
Du kan finde dit UUID på diskene med 'ls -ls /dev/disk/by-uuid/' som fx:
[root@integration2 bin]# ls -ls /dev/disk/by-uuid/
total 0
0 lrwxrwxrwx. 1 root root 10 Dec 14 19:22 6ac4db93-389d-49a8-9659-43096e5050e2 -> ../../dm-0
0 lrwxrwxrwx. 1 root root 10 Dec 14 19:22 6c534f9c-8ea4-4964-8b84-6d3d571215e1 -> ../../dm-1
0 lrwxrwxrwx. 1 root root 10 Dec 14 19:22 e6d35c81-ce24-4af2-9468-68f2a11a78cc -> ../../sda2
UUID er noget der bliver sat når du formaterer disken så det ændre sig ikke med mindre du formaterer disken igen.
Hej Julemand.
Jeg har
Jeg har såmænd også prøvet med UUID ( skulle nok have nævnt dette)
Min pointe er hvorfor den bytter om på scsi0 og scsi1 - har det nogen effekt som så( hvilket det har for os)
Eftersom systemet accepterer og starter op hvor den dermed bare mounter /dev/sdb2 som / men fejler i at mounte sdb1 (nu sda)
Som jeg kan se det - sker det ved reboot og opstarten af systemet.
Hvis den loader
scsi0
scsi1
Starter systemet korrekt op
modsat
scsi1
scsi0
Så får jeg ikke mountet hele det drev hvor mine programmer ligger
Er det netop i Hyper-V eller i Linux dette problem ?
Årsagen er at load af Linux
Husk på at UUID ikke kun skal angives i fstab men også ved angivelse af root= som kerneparameter du har angivet i bootloader.
hej Julemand.
Takker for
Takker for uddybende viden.
Men eftersom jeg har prøvet både med UUID og med /dev/sda - rettet i grub samt i /etc/fstab.
For at forklare det bedre -
/dev/sda --> Systemdisk indeholdende /boot / og swap
/dev/sdb --> mountet og indeholder vores ERP system - Mountes i /mera
Når diskene byttes om ved boot - Fjernes muligheden for mount af /mera og systeet starter ikke korrekt. Så kan der rebootes indtil systemet starter rigtigt op. Jeg ved bare ikke om problemet ligger i hvordan Hyper-V leverer diskene til den virtuelle maskine - eller om det ligger i Linux.
Og hvordan kan jeg afhjælpe dette. SYntes jeg har prøvet alt mht både UUID /dev/sdX boot muligheder - så jeg er om muligt derhenne hvor jeg skal kigge på hvordan Hper-V leverer disse 2 harddiske ind til den virtuelle host
#4
Altså når du oplever
Altså når du oplever problemet så tyder det jo på der er noget der stadig bruger /dev/sda og /dev/sdb i forbindelse med mount. Spørgsmålet er så hvad det er der stadig gør brug af dette og her kunne man måske søge igennem alle filer i /etc og se om der er nogen referencer til disse diske.
Prøv næste gang problemet optræder at køre en 'sudo journalctl -b > /sti/til/logfil' og upload evt. den så jeg kan se den. Den vil udover dmesg også indeholde alt log fra andre systemer som fx den del der foretager mount af enheder.
Jeg tvivler stærkt på at problemet kan løses ved at se på Hyper-V da det du oplever er ret normalt for mange installationer uden Hyper-V. Hvis du ender med at løse det så vil du ihvertfald have et system der stadig har en risiko for at diske ikke mountes korrekt.