Posts by sebres

    Ich möchte zwar nicht spekulieren ob es ein bug ist (steht ja eindeutig "einmal ausschalten";),
    aber es ist in der tat ein bisschen hässlich:


    - gehe zu Medien, wähle image; gehe zu Steuerung, schalte aus, schalte ein;
    und wenn alles fertig ist, wieder alles zurück:
    - gehe zu Einstellungen, wechsle Boot-Reihenfolge HDD oben; gehe zu Steuerung, schalte aus, schalte ein.

    Ich nutze QEMU/KVM bei der Arbeit und hatte nie Probleme kurz von Image/CDROM zu booten ohne den Guest unbedingt ausschalten zu müssen:

    • entweder über virsh edit (es ändert auch runtime Werte)
    • oder über XML Anpassen und libvirt-bin reload
    • oder direkt über Kommando qemu -boot once=d ...

    Wie auch immer (ich kann mir viele Möglichkeiten vorstellen das zu skripten)... und es ist mir ein Rätsel warum es unbedingt so umständlich gemacht werden soll.
    Gut das diese Aktivität nur selten gebraucht wird... aber bei dem letzten Migrieren habe ich es mindestens 10 mal gemacht (boot loader war kaputt, so den Vorgang boot-live-cd/ändern/zurück-zu-hdd/versuch/noch-kaputt... und das 10 mal wiederholt), und kann bestätigen - es ist wirklich wirklich lästig.

    If the question is still acute, resp. interesting for other people may still need that...

    1. Backup/make Snapshot/whatever is needed (in order to restore if something below were going wrong).
    2. Be sure you've same system (distribution/revision) installed on both hosts, so do update/upgrade on both sides.
      Also check rsync is installed.
    3. Reboot both and login as root (or sudo -s) on source and target systems
    4. If you want migrate some kernel-less system (container virtual guest) like OpenVZ, LXC, etc to host with a kernel (KVM, etc) you have to install getty or mingetty and enable tty's, otherwise simply bypass this step.
      You can also do that later if you've (chroot capable) live CD, but better at least install mingetty before you start migration.
      On the source VM:
      apt install mingetty
      then edit inittab
      nano /etc/inittab
      and add this lines or check they are already there:
      Code
      1. # Run gettys in standard run levels
      2. 1:2345:respawn:/sbin/mingetty tty1
      3. 2:2345:respawn:/sbin/mingetty tty2
      4. 3:2345:respawn:/sbin/mingetty tty3
      5. 4:2345:respawn:/sbin/mingetty tty4
      6. 5:2345:respawn:/sbin/mingetty tty5
      7. 6:2345:respawn:/sbin/mingetty tty6
    5. Now on the source host create an exclude list /tmp/rsexcl.txt for rsync (directory names which should be ignored by migration):
      { for i in /boot /proc /sys /tmp /dev /run /var/run /var/lock /etc/fstab /etc/mtab /etc/resolv.conf /etc/conf.d/net /etc/network/interfaces /etc/networks '/etc/sysconfig/network*' /etc/sysconfig/hwconf /etc/sysconfig/ip6tables-config /etc/sysconfig/kernel /etc/hostname /etc/HOSTNAME /etc/hosts '/etc/modprobe*' /etc/modules /net /lib/modules /etc/rc.conf '/usr/share/nova-agent*' '/usr/sbin/nova-agent*' '/etc/init.d/nova-agent*' /etc/ips /etc/ipaddrpool /etc/ips.dnsmaster /etc/resolv.conf /etc/sysconfig/network-scripts/ifcfg-eth0 /etc/udev /lib/udev; do echo "$i"; done; } > /tmp/rsexcl.txt
      You can also add your own large directories (e. g. /var/mail, /home/user/data) to this file in order to speedup initial step of migration (they will be copied at end, see step 9).
    6. And start the initial migration (replace TARGET-SERVER with IP or name of your target host):
      rsync --exclude-from="/tmp/rsexcl.txt" --delete --numeric-ids -avpogtStlHz -e "ssh -o Compression=no" / root@TARGET-SERVER:/
      Now wait until it gets ready.
    7. Then switch to target host and reboot it.
      If it does not boot successfully, boot from LiveCD in rescue mode, select your root and start shell.
      Then try to reinstall and update grub:
      Code
      1. apt-get install --reinstall grub
      2. update-grub
      It should be bootable now.
    8. Check and change in case of need the remaining configuration like network interfaces, IPs, etc.
      Sometimes tty1 is disabled (you've terminal on tty2..tty6 only), if you need it, just enable `getty@tty1` service (here for systemd):
      systemctl enable getty@tty1
    9. Now you can copy the rest of your data (here the 2 remaining directories that have been added in exclude-list in step 5):
      rsync --numeric-ids -avpogtStlHz --relative -e "ssh -o Compression=no" /var/mail /home/user/data root@TARGET-SERVER:/
      You can repeat this several times in order to do an incremental update, if your domains are not yet actualized and some mails still delivered to the old (source) host. Don't use --delete option here (so only new mails or data).

    That's it.

    iperf Ergebnisse:

    Aber wget ist schnell:

    Das gleiche Ergebnis sehe ich bei wget auf dem anderen VPS (alten Provider).


    Scheint irgendwas zwischen beiden Servern zu sein (oder nur bei bestimmten Paketen eben).

    Hi all,

    bin gerade während der Migration-Phase, so kopiere meine Daten von dem alten Provider zu netcup (VPS 500 G8).


    Habe echt miserable Speed (2,5Mbit) beim rsync oder scp, auch bei großen einzelnen Dateien (bis zu 2GB)...


    Weiß zwar nicht was ssh mit UDP haben soll, aber komischerweise bekomme ich den gleichen Throughput als in dem Antwort https://unix.stackexchange.com/a/310560 erwähnt - und zwar ca. 250KB/s.
    An der Gegenseite kann es eigentlich nicht liegen.
    Und wenn ich zwei Kopie-Prozesse in parallel starte, habe ich ca. 230KB/s je Prozess (aber insgesamt schon mal das doppelte Durchsatz).


    Ich habe zwar keine eigene UDP FP (flood protection) aktiviert, aber irgendwo gelesen das netcup irgendeine Art DDoS Protection hat.
    Weiß jemand ob es damit zusammen hängen könnte und falls nicht was evtl sonst dies verursachen könnte.


    Die mittlere Geschwindigkeit von 2,5Mbit ist irgendwie nicht das was man erwartet (auch von VPS nicht;).
    Ich habe auch ein Test von selben Server zu einem anderen VPS-Host (nicht bei netcup) gemacht und bekomme dort bis zu 12MB/s (ca. 100 Mbit) in AVG.


    Diff
    1. - # scp /git-1.tar.gz my-vps-on-netcup.de:/
    2. + # scp /git-1.tar.gz other-test-server.de:/
    3. - git-1.tar.gz 100% 736MB 232.7KB/s 54:00
    4. + git-1.tar.gz 100% 736MB 12.2MB/s 01:00


    Nebenbei, ich kann auch nicht wirklich die Eckdaten von meinem NIC "auswerten" (ich dachte virtio soll bei KVM von kernel gemanagt werden, wird es nicht?):

    Shell-Script
    1. # cat /sys/class/net/ens3/speed
    2. -1
    3. # ethtool ens3 | greep Speed
    4. Speed: Unknown


    Danke im Voraus für jeden Hinweis.
    MFG, Serg.