Сообщение Re[42]: dotnet vs java 2016-2020 от 10.04.2016 1:50
Изменено 10.04.2016 10:25 Cyberax
Здравствуйте, vdimas, Вы писали:
C>>Я привёл ссылку на _исходник_.
V>Это исходники IBM LGuest, которые на тот момент никаким боком к KVM не относились.
Это исходники драйверов для virtio, которые никоим образом к lguest не относятся.
V>KVM — это kernel virtual machine. Поддержка виртуализации и есть в ядре. Например, ядро с поддержкой KVM и ядро с поддержкой Xen — это разные ядра (собранные с разными опциями/зависимостями).
Нет. KVM — это просто ядерный модуль, который позволяет использовать возможности виртуализации CPU. Он не имеет зависимостей сам по себе и может использоваться для запуска совершенно немодифицированных операционок (даже 16-битных).
В пользовательском пространстве KVM'ом обычно управляет qemu, но это не является обязательным.
Xen — это bare-metal гипервизор, который может использовать Linux в качестве гостя (domU) и как хост-систему (dom0). Гость может быть совершенно не модифицированным.
Ну а Virtio — это механизм создания эффективных драйверов для гостевых систем и может использоваться разными гипервизорами. Он существует в немного разных формах с 2003-го года, когда IBM добавила его для OS/390. Для сети и блочных устройств он появился в 2006-м году в Линуксе. Сейчас его поддерживает qemu, Xen и (о ужас!) Hyper-V.
V>http://lxr.free-electrons.com/source/drivers/virtio/?v=2.6.32
V>Упс, это только модули со стороны ядра. Со стороны гостевой ОС должны быть драйверы, конкретно для блочных устройств это virtio_blk. Не хочешь продолжить свои исследования? ))
Нет. Со стороны гостевой OS ничего не надо. Virtio можно использовать даже в режиме полной эмуляции qemu, в том числе для другой архитектуры.
Вот код хост-стороны того же virtio net: https://github.com/qemu/qemu/blob/331ac65963ab74dd84659b748affa0b111486f06/hw/net/virtio-net.c Там же и timestamp времени создания файла — 2007-й год.
V>>>Твой 6-й KVM еще относительно долго периодически зависал без признаков жизни в различных сценариях, чтобы заслужить быть включенным в репозиторий. Вот откуда растут ноги у разных "реальностей" вокруг KVM.
C>>Бредим.
"6-й KVM" достоин отдельного лулза.
C>>Какой 6-й версии, что за бред?
V>И точно бред:
V>
Тот релиз соответствует ядру 2.6.25, которое было 17 апреля 2008-го года.
V>KVM в версии 6 мигрировала на технологию VirtIO из LGuest. Ты даешь исходники именно на код из последнего. Осталось узнать, когда вышла KVM 6.0 и навсегда перестать растопыривать пальцы вейером.
Да я понимаю, ты нахватался слов из wiki-страниц, часто написанных в районе 2010-го года не очень грамотными студентами. Реального опыта у тебя полный ноль.
V>Ограничения проброса SCSI (passthrough):
V> нет multipath;
V> HBA адаптер не может участвовать в миграциях виртуальной машины;
V> чтобы отправить SCSI команду, виртуальное окружение должно иметь эксклюзивный доступ к диску;
V> две виртуальных машины не могут использовать устройство одновременно.
Ух ты! Прямой доступ к железу означает прямой доступ к железу!
V>Похоже, ты не понимаешь, как работает DMA, ы-ы-ы. Канал DMA будет занят, пока гость не проснется для обработки прерывания от него по окончании передачи.
Усиленно читаем вики-статьи про IOMMU.
C>>Самый быстрый сейчас стек — это userspace-реализация в DPDK.
V>Маркетинговый булшит. Ничем серьезно от того же Solarflare на OpenOnload ни по каким меркам не отличается.
Можно и его. Это тот же DPDK, но только не от Intel.
C>>Для CERN мы делали чисто софтовый маршрутизатор на 30ГБ на машину. Да-да, с виртуализацией.
V>Ну вот и спалился. 30Gb на машину не то же самое, что 10Gb на карточку.
Можно и на карту. Зависит от потребностей.
V>Согласен. 19-й век. Даже используя OpenOnload. Без прокрутки в спине ожидания Linux работать адекватно отказывается. Стоит уйти в спячку — и всему хана, из-за медленного пробуждения. А спин ожидания — это целое простаивающее ядро. Как ни крути, а г-но на палочке.
Читаем как работает NAPI.
V>Если нужна wire speed, то необходимо и достаточно, чтобы каждый приходящий по сетке пакет было куда складывать и чтобы по готовности устройства к записи было откуда взять данные и записать в него. Так просто, но недоступно на Linux.
http://man7.org/linux/man-pages/man3/aio_read.3.html
C>>Да, специально заточенные кластеры, для научных вычислений (и не только). На вполне себе KVM с особым цинизмом.
V>Зачем KVM? Вы машинное время предоставляете? ))
Например, для миграции с плохого железа и для оптимизации сетевой топологии в ходе работы. Миграция особенно важна — кластеры на MPI редко переживают остановку отдельных машин. А если машин несколько тысяч и задача требует пару дней счёта, то такая вероятность начинает быть вполне себе значительной.
C>>Я привёл ссылку на _исходник_.
V>Это исходники IBM LGuest, которые на тот момент никаким боком к KVM не относились.
Это исходники драйверов для virtio, которые никоим образом к lguest не относятся.
V>KVM — это kernel virtual machine. Поддержка виртуализации и есть в ядре. Например, ядро с поддержкой KVM и ядро с поддержкой Xen — это разные ядра (собранные с разными опциями/зависимостями).
Нет. KVM — это просто ядерный модуль, который позволяет использовать возможности виртуализации CPU. Он не имеет зависимостей сам по себе и может использоваться для запуска совершенно немодифицированных операционок (даже 16-битных).
В пользовательском пространстве KVM'ом обычно управляет qemu, но это не является обязательным.
Xen — это bare-metal гипервизор, который может использовать Linux в качестве гостя (domU) и как хост-систему (dom0). Гость может быть совершенно не модифицированным.
Ну а Virtio — это механизм создания эффективных драйверов для гостевых систем и может использоваться разными гипервизорами. Он существует в немного разных формах с 2003-го года, когда IBM добавила его для OS/390. Для сети и блочных устройств он появился в 2006-м году в Линуксе. Сейчас его поддерживает qemu, Xen и (о ужас!) Hyper-V.
V>http://lxr.free-electrons.com/source/drivers/virtio/?v=2.6.32
V>Упс, это только модули со стороны ядра. Со стороны гостевой ОС должны быть драйверы, конкретно для блочных устройств это virtio_blk. Не хочешь продолжить свои исследования? ))
Нет. Со стороны гостевой OS ничего не надо. Virtio можно использовать даже в режиме полной эмуляции qemu, в том числе для другой архитектуры.
Вот код хост-стороны того же virtio net: https://github.com/qemu/qemu/blob/331ac65963ab74dd84659b748affa0b111486f06/hw/net/virtio-net.c Там же и timestamp времени создания файла — 2007-й год.
V>>>Твой 6-й KVM еще относительно долго периодически зависал без признаков жизни в различных сценариях, чтобы заслужить быть включенным в репозиторий. Вот откуда растут ноги у разных "реальностей" вокруг KVM.
C>>Бредим.
"6-й KVM" достоин отдельного лулза.
C>>Какой 6-й версии, что за бред?
V>И точно бред:
V>
Это не версия 6.0, это версия 60. В KVM они увеличивалась каждый tarball-релиз до объединения в официальное ядро и некоторое время после. Сейчас у неё нет своей нумерации версий.V>How to use Virtio
V> Get kvm version >= 60
Тот релиз соответствует ядру 2.6.25, которое было 17 апреля 2008-го года.
V>KVM в версии 6 мигрировала на технологию VirtIO из LGuest. Ты даешь исходники именно на код из последнего. Осталось узнать, когда вышла KVM 6.0 и навсегда перестать растопыривать пальцы вейером.
Да я понимаю, ты нахватался слов из wiki-страниц, часто написанных в районе 2010-го года не очень грамотными студентами. Реального опыта у тебя полный ноль.
V>Ограничения проброса SCSI (passthrough):
V> нет multipath;
V> HBA адаптер не может участвовать в миграциях виртуальной машины;
V> чтобы отправить SCSI команду, виртуальное окружение должно иметь эксклюзивный доступ к диску;
V> две виртуальных машины не могут использовать устройство одновременно.
Ух ты! Прямой доступ к железу означает прямой доступ к железу!
V>Похоже, ты не понимаешь, как работает DMA, ы-ы-ы. Канал DMA будет занят, пока гость не проснется для обработки прерывания от него по окончании передачи.
Усиленно читаем вики-статьи про IOMMU.
C>>Самый быстрый сейчас стек — это userspace-реализация в DPDK.
V>Маркетинговый булшит. Ничем серьезно от того же Solarflare на OpenOnload ни по каким меркам не отличается.
Можно и его. Это тот же DPDK, но только не от Intel.
C>>Для CERN мы делали чисто софтовый маршрутизатор на 30ГБ на машину. Да-да, с виртуализацией.
V>Ну вот и спалился. 30Gb на машину не то же самое, что 10Gb на карточку.
Можно и на карту. Зависит от потребностей.
V>Согласен. 19-й век. Даже используя OpenOnload. Без прокрутки в спине ожидания Linux работать адекватно отказывается. Стоит уйти в спячку — и всему хана, из-за медленного пробуждения. А спин ожидания — это целое простаивающее ядро. Как ни крути, а г-но на палочке.
Читаем как работает NAPI.
V>Если нужна wire speed, то необходимо и достаточно, чтобы каждый приходящий по сетке пакет было куда складывать и чтобы по готовности устройства к записи было откуда взять данные и записать в него. Так просто, но недоступно на Linux.
http://man7.org/linux/man-pages/man3/aio_read.3.html
C>>Да, специально заточенные кластеры, для научных вычислений (и не только). На вполне себе KVM с особым цинизмом.
V>Зачем KVM? Вы машинное время предоставляете? ))
Например, для миграции с плохого железа и для оптимизации сетевой топологии в ходе работы. Миграция особенно важна — кластеры на MPI редко переживают остановку отдельных машин. А если машин несколько тысяч и задача требует пару дней счёта, то такая вероятность начинает быть вполне себе значительной.
Re[42]: dotnet vs java 2016-2020
Здравствуйте, vdimas, Вы писали:
C>>Я привёл ссылку на _исходник_.
V>Это исходники IBM LGuest, которые на тот момент никаким боком к KVM не относились.
Это исходники драйверов для virtio, которые никоим образом к lguest не относятся.
V>KVM — это kernel virtual machine. Поддержка виртуализации и есть в ядре. Например, ядро с поддержкой KVM и ядро с поддержкой Xen — это разные ядра (собранные с разными опциями/зависимостями).
Нет. KVM — это просто ядерный модуль, который позволяет использовать возможности виртуализации CPU. Он не имеет зависимостей сам по себе и может использоваться для запуска совершенно немодифицированных операционок (даже 16-битных).
В пользовательском пространстве KVM'ом обычно управляет qemu, но это не является обязательным.
Xen — это bare-metal гипервизор, который может использовать Linux в качестве гостя (domU) и как хост-систему (dom0). Гость может быть совершенно не модифицированным.
Ну а Virtio — это механизм создания эффективных драйверов для гостевых систем и может использоваться разными гипервизорами. Он существует в немного разных формах с 2003-го года, когда IBM добавила его для OS/390. Для сети и блочных устройств он появился в 2006-м году в Линуксе. Сейчас его поддерживает qemu, Xen и (о ужас!) Hyper-V.
V>http://lxr.free-electrons.com/source/drivers/virtio/?v=2.6.32
V>Упс, это только модули со стороны ядра. Со стороны гостевой ОС должны быть драйверы, конкретно для блочных устройств это virtio_blk. Не хочешь продолжить свои исследования? ))
Это драйверы именно ГОСТЕВОЙ ОС. Со стороны хост-OS ничего не надо, так что Virtio можно использовать даже в режиме полной эмуляции qemu, в том числе для другой архитектуры.
Вот код хост-стороны того же virtio net: https://github.com/qemu/qemu/blob/331ac65963ab74dd84659b748affa0b111486f06/hw/net/virtio-net.c Там же и timestamp времени создания файла — 2007-й год.
V>>>Твой 6-й KVM еще относительно долго периодически зависал без признаков жизни в различных сценариях, чтобы заслужить быть включенным в репозиторий. Вот откуда растут ноги у разных "реальностей" вокруг KVM.
C>>Бредим.
"6-й KVM" достоин отдельного лулза.
C>>Какой 6-й версии, что за бред?
V>И точно бред:
V>
Тот релиз соответствует ядру 2.6.25, которое было 17 апреля 2008-го года.
V>KVM в версии 6 мигрировала на технологию VirtIO из LGuest. Ты даешь исходники именно на код из последнего. Осталось узнать, когда вышла KVM 6.0 и навсегда перестать растопыривать пальцы вейером.
Да я понимаю, ты нахватался слов из wiki-страниц, часто написанных в районе 2010-го года не очень грамотными студентами. Реального опыта у тебя полный ноль.
V>Ограничения проброса SCSI (passthrough):
V> нет multipath;
V> HBA адаптер не может участвовать в миграциях виртуальной машины;
V> чтобы отправить SCSI команду, виртуальное окружение должно иметь эксклюзивный доступ к диску;
V> две виртуальных машины не могут использовать устройство одновременно.
Ух ты! Прямой доступ к железу означает прямой доступ к железу!
V>Похоже, ты не понимаешь, как работает DMA, ы-ы-ы. Канал DMA будет занят, пока гость не проснется для обработки прерывания от него по окончании передачи.
Усиленно читаем вики-статьи про IOMMU.
C>>Самый быстрый сейчас стек — это userspace-реализация в DPDK.
V>Маркетинговый булшит. Ничем серьезно от того же Solarflare на OpenOnload ни по каким меркам не отличается.
Можно и его. Это тот же DPDK, но только не от Intel.
C>>Для CERN мы делали чисто софтовый маршрутизатор на 30ГБ на машину. Да-да, с виртуализацией.
V>Ну вот и спалился. 30Gb на машину не то же самое, что 10Gb на карточку.
Можно и на карту. Зависит от потребностей.
V>Согласен. 19-й век. Даже используя OpenOnload. Без прокрутки в спине ожидания Linux работать адекватно отказывается. Стоит уйти в спячку — и всему хана, из-за медленного пробуждения. А спин ожидания — это целое простаивающее ядро. Как ни крути, а г-но на палочке.
Читаем как работает NAPI.
V>Если нужна wire speed, то необходимо и достаточно, чтобы каждый приходящий по сетке пакет было куда складывать и чтобы по готовности устройства к записи было откуда взять данные и записать в него. Так просто, но недоступно на Linux.
http://man7.org/linux/man-pages/man3/aio_read.3.html
C>>Да, специально заточенные кластеры, для научных вычислений (и не только). На вполне себе KVM с особым цинизмом.
V>Зачем KVM? Вы машинное время предоставляете? ))
Например, для миграции с плохого железа и для оптимизации сетевой топологии в ходе работы. Миграция особенно важна — кластеры на MPI редко переживают остановку отдельных машин. А если машин несколько тысяч и задача требует пару дней счёта, то такая вероятность начинает быть вполне себе значительной.
C>>Я привёл ссылку на _исходник_.
V>Это исходники IBM LGuest, которые на тот момент никаким боком к KVM не относились.
Это исходники драйверов для virtio, которые никоим образом к lguest не относятся.
V>KVM — это kernel virtual machine. Поддержка виртуализации и есть в ядре. Например, ядро с поддержкой KVM и ядро с поддержкой Xen — это разные ядра (собранные с разными опциями/зависимостями).
Нет. KVM — это просто ядерный модуль, который позволяет использовать возможности виртуализации CPU. Он не имеет зависимостей сам по себе и может использоваться для запуска совершенно немодифицированных операционок (даже 16-битных).
В пользовательском пространстве KVM'ом обычно управляет qemu, но это не является обязательным.
Xen — это bare-metal гипервизор, который может использовать Linux в качестве гостя (domU) и как хост-систему (dom0). Гость может быть совершенно не модифицированным.
Ну а Virtio — это механизм создания эффективных драйверов для гостевых систем и может использоваться разными гипервизорами. Он существует в немного разных формах с 2003-го года, когда IBM добавила его для OS/390. Для сети и блочных устройств он появился в 2006-м году в Линуксе. Сейчас его поддерживает qemu, Xen и (о ужас!) Hyper-V.
V>http://lxr.free-electrons.com/source/drivers/virtio/?v=2.6.32
V>Упс, это только модули со стороны ядра. Со стороны гостевой ОС должны быть драйверы, конкретно для блочных устройств это virtio_blk. Не хочешь продолжить свои исследования? ))
Это драйверы именно ГОСТЕВОЙ ОС. Со стороны хост-OS ничего не надо, так что Virtio можно использовать даже в режиме полной эмуляции qemu, в том числе для другой архитектуры.
Вот код хост-стороны того же virtio net: https://github.com/qemu/qemu/blob/331ac65963ab74dd84659b748affa0b111486f06/hw/net/virtio-net.c Там же и timestamp времени создания файла — 2007-й год.
V>>>Твой 6-й KVM еще относительно долго периодически зависал без признаков жизни в различных сценариях, чтобы заслужить быть включенным в репозиторий. Вот откуда растут ноги у разных "реальностей" вокруг KVM.
C>>Бредим.
"6-й KVM" достоин отдельного лулза.
C>>Какой 6-й версии, что за бред?
V>И точно бред:
V>
Это не версия 6.0, это версия 60. В KVM они увеличивалась каждый tarball-релиз до объединения в официальное ядро и некоторое время после. Сейчас у неё нет своей нумерации версий.V>How to use Virtio
V> Get kvm version >= 60
Тот релиз соответствует ядру 2.6.25, которое было 17 апреля 2008-го года.
V>KVM в версии 6 мигрировала на технологию VirtIO из LGuest. Ты даешь исходники именно на код из последнего. Осталось узнать, когда вышла KVM 6.0 и навсегда перестать растопыривать пальцы вейером.
Да я понимаю, ты нахватался слов из wiki-страниц, часто написанных в районе 2010-го года не очень грамотными студентами. Реального опыта у тебя полный ноль.
V>Ограничения проброса SCSI (passthrough):
V> нет multipath;
V> HBA адаптер не может участвовать в миграциях виртуальной машины;
V> чтобы отправить SCSI команду, виртуальное окружение должно иметь эксклюзивный доступ к диску;
V> две виртуальных машины не могут использовать устройство одновременно.
Ух ты! Прямой доступ к железу означает прямой доступ к железу!
V>Похоже, ты не понимаешь, как работает DMA, ы-ы-ы. Канал DMA будет занят, пока гость не проснется для обработки прерывания от него по окончании передачи.
Усиленно читаем вики-статьи про IOMMU.
C>>Самый быстрый сейчас стек — это userspace-реализация в DPDK.
V>Маркетинговый булшит. Ничем серьезно от того же Solarflare на OpenOnload ни по каким меркам не отличается.
Можно и его. Это тот же DPDK, но только не от Intel.
C>>Для CERN мы делали чисто софтовый маршрутизатор на 30ГБ на машину. Да-да, с виртуализацией.
V>Ну вот и спалился. 30Gb на машину не то же самое, что 10Gb на карточку.
Можно и на карту. Зависит от потребностей.
V>Согласен. 19-й век. Даже используя OpenOnload. Без прокрутки в спине ожидания Linux работать адекватно отказывается. Стоит уйти в спячку — и всему хана, из-за медленного пробуждения. А спин ожидания — это целое простаивающее ядро. Как ни крути, а г-но на палочке.
Читаем как работает NAPI.
V>Если нужна wire speed, то необходимо и достаточно, чтобы каждый приходящий по сетке пакет было куда складывать и чтобы по готовности устройства к записи было откуда взять данные и записать в него. Так просто, но недоступно на Linux.
http://man7.org/linux/man-pages/man3/aio_read.3.html
C>>Да, специально заточенные кластеры, для научных вычислений (и не только). На вполне себе KVM с особым цинизмом.
V>Зачем KVM? Вы машинное время предоставляете? ))
Например, для миграции с плохого железа и для оптимизации сетевой топологии в ходе работы. Миграция особенно важна — кластеры на MPI редко переживают остановку отдельных машин. А если машин несколько тысяч и задача требует пару дней счёта, то такая вероятность начинает быть вполне себе значительной.