Ist das normal [...]
Ja.
bin ich unfreiwilliges Opfer eines Konfigurationsexperiments?
Nein.
Das hängt davon ab, wie die Festplatte eingebunden ist (Stichwort virtio). Falls es bei Dir Probleme macht, kann der Support es normalerweise einfach umstellen. Normalerweise ist das aber nicht notwendig, wenn man überall konsequent die UUID der Partition verwendet. Diese findest Du z.B. über blkid heraus und kannst sie danach u.a. in der /etc/fstab verwenden.
Warum das bei verschiedenen Produkten anders ist, weiß ich auch nicht. Ich könnte nur vermuten, dass der jeweils andere Modus bei Single/Dual Core Systemen vielleicht eine bessere Performance erzielt oder so andere Probleme umgangen werden. In diesem Punkt unterscheiden sich die beiden Tarife nämlich. Oder eines der beiden Hostsysteme läuft noch unter einer älteren Version, wo das nicht vollständig unterstützt wird. Letzen Endes wird das nur netcup selbst aufklären können.
MfG Christian
Ich hatte das halt noch nie gesehen, dass die Platte als sda läuft.
Außerhalb von ncLabs habe ich es bei netcup bisher auch noch nie gesehen, und dort auch nur auf expliziten Wunsch… 
MfG Christian
Guten Morgen,
/dev/sda steht nach einer Installation mit einem aktuellen Image bei allen vServern / Root-Server / Storage und VPS zur Verfügung. Die Optimierung bieten wir unabhängig vom Tarif an.
Mit freundlichen Grüßen
Felix Preuß
Wie darf ich diese Optimierung verstehen? Also was genau der Unterschied zwischen vda und sda ist, hab mich damit noch nicht so tiefgründig befasst.
Zusätzlich könnte man auch die TRIM-Befehle mittels der Mountoption "discard" oder über fstrim durchreichen, was besonders für die Snapshots von Vorteil ist, da eine Defragmentierung dadurch unnötig wird. Je nach Konfiguration könnte man dadurch auch Speicherplatz am Hostsystem sparen. Ob das bei den aktuellen Produkten genutzt wird, kann ich nicht mangels Testsystem nicht sagen.
MfG Christian
Also ich habe jetzt den RS 2000 G7 SSD über eine Imageinstallation eingerichtet und weiterhin vda und nicht sda (was ich ich mir aber irgendwie schon denken konnte)...
Welches Image wurde installiert?
Ich möchte hier nochmal sicher gehen: Wenn ich jetzt einen neuen root-Server bestelle (egal welchen RS 1000 bis 8000 G7) bekomme ich sda anstelle vda?
Es hat nichts mit den neuen Tarifen zu tun, sondern mit einer Umstellung der vorgefertigten Images. Bei einer Neuinstallation eines jeden auf KVM basierenden Server mit einem aktuellen Image (Debian Jessie, Ubuntu 16, Fedora 24 etc.) erfolgt die Umstellung von "vda" auf "sda".
Hallo,
Es hat nichts mit den neuen Tarifen zu tun, sondern mit einer Umstellung der vorgefertigten Images. Bei einer Neuinstallation eines jeden auf KVM basierenden Server mit einem aktuellen Image (Debian Jessie, Ubuntu 16, Fedora 24 etc.) erfolgt die Umstellung von "vda" auf "sda".
das verstehe ich anders. Es hat nichts mit den Images aber alles mit dem kvm-Aufruf zu tun.
Der Thread hat mich dazu gebracht, damit auf meiner Entwicklermaschine zu experimentieren. Dort herrscht ständig Platzmangel, da alle Projekte ihre eigene KVM-Jessie haben. Ich starte meine VMs immer direkt per Kommandozeile mit kvm.
Bisher habe ich meine Images mit
-drive file=$DISK_IMG,index=0,media=disk,format=$DISK_IMG_FORMAT,if=virtio,cache=none
eingebunden und die Partitionen waren vda's.
Nach der Änderung in
-drive file=$DISK_IMG,index=0,media=disk,format=$DISK_IMG_FORMAT,if=none,cache=none,id=drive0,discard=unmap \
-device virtio-scsi-pci,id=scsi0 \
-device scsi-hd,bus=scsi0.0,drive=drive0
waren die Partitionen in sda's geändert.
Dank der allgemein bei Jessie verwendeten UUIDs in der fstab war keine weitere Änderung notwendig.
Den großen Vorteil bringt nun die Option discard=unmap. Damit kann nicht benutzter Speicherplatz im Host wieder freigegeben werden (eigentlich ne SSD-Geschichte: killerbees19 hat ja fstrim erwähnt).
Das kann man dann an den Images sehen, wenn man in der VM mal trimmt:
xxx@yyy:~/Qemu VMs/zzz$ ssh root@zzz
root@zzz:~# fstrim -a -v
/: 25,2 GiB (27044970496 bytes) trimmed
root@zzz:~# exit
xxx@yyy:~/Qemu VMs/zzz$ ls -lhs
insgesamt 1,9G
1,9G -rw------- 1 xxx xxx 3,4G Aug 14 22:09 zzz.qcow2
0 -rw-r--r-- 1 xxx xxx 0 Aug 14 19:13 kvm.log
4,0K -rwx------ 1 xxx xxx 849 Aug 13 17:59 vm.sh
xxx@yyy:~/Qemu VMs/zzz$Der Effekt ist also deutlich: links der tatsächlich belegte Platz von zzz.qcow2, rechts die Dateigröße: qcow2 als Sparse-File.
Das Potential liegt IMHO vor allem in dem Shrinken der Images ohne Rumhampeln (s. z.B. Shrink Qcow2 Disk Files - Proxmox VE).
Dieser Vorteil wird in den Netcup-Images auch genutzt. Das von mir genutzte Jessie-Image (installiert in den letzten Tagen) hatte zwar keine discard-Option in der /etc/fstab, mit der der Speicherplatz von der VM sofort zurückgegeben wird, es existiert aber ein Netcup-spezifischer CronJob, der fstrim ausführt.
Der Vorteil für Netcup ist, dass der Festplattenplatz effizienter genutzt werden kann. Der mittelbare Vorteil für den Kunden ist der gute Preis.
Falls ich falsch liege oder was vergessen habe, bitte Rückmeldung!
Viele Grüße!
Danke für die genaue Analyse, vor allem die Sache mit dem Cronjob! 
Gerade im Hinblick auf die Storageserver würde das sehr viel Sinn machen… (nur geht der Vorteil halt schnell verloren, wenn jemand über eine ISO installiert und die Option nicht setzt.)
Zu Hause wäre mein KVM-Host auch schon an Platzmangel gestorben, wenn ich dieses Feature nicht nutzen würde. Bei mir halt mit Raw-Images über libvirt. Eine ~100GB SSD ist für viele Debian-VMs halt nicht gerade viel, wenn Datenverzeichnisse auch noch mit drauf müssen.
MfG Christian
Kann man das auch irgendwie umstellen ohne ein neues Image zu installieren?
Von Kundenseite müsste es ja genügen virtio_blk durch virtio_scsi zu ersetzen, nur der Host muss natürlich auch die enstprechende Unterstützung aktivieren. Beim Netzwerk kann man ja im VCP den Treiber wählen, für die Festplatte sehe ich aber nichts derartiges.
