2016-08-03 2 views
-1

На одном из наших гипервизоров, работающих под управлением Xen (v.4.6.0 поверх Debian Jessie на Dell R420), когда мы настраиваем domU для HVM и подключаемся к консоли через VNC, соединение отображает статическое изображение и, как представляется, не принимает входной сигнал мыши или клавиатуры (что позволяет думать, что VM заморожена/не реагирует). Поведение сохраняется после закрытия и повторного подключения к VNC, но теперь отображается ввод мыши/клавиатуры из предыдущего сеанса (так что если вы вставляете три раза, вы можете видеть, что соответствующая радио или кнопка ввода подсвечивается после закрытия/открытия соединения VNC , но вам нужно снова закрыть окно, чтобы увидеть, где находится следующий вход, что делает его непригодным).Xen HVM domU VNC не освежающий экран

У нас Xen работает плавно на трех других физических машинах с HVM-сконфигурированными domUs (2x Debian Jessie, 1x Ubuntu Xenial, все с v.4.6.0) и сравнивали то, что могло быть другим, мы заметили, что QEMU может быть обновлены на неудобном хосте Xen. После обновления QEMU с 1.2.2 до 1.2.5 (соответствующего версии на рабочих хостах) и перезагрузки проблема все еще сохраняется. Мы скопировали конфигурацию виртуальной машины на другой хост с успешными результатами, заставив нас поверить, что на этом компьютере есть что-то изолированное.

Результаты кошачьих/SYS/гипервизора/свойства/возможности

xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64

Результаты хг Информация:

host     : vm-host 
release    : 3.16.0-4-amd64 
version    : #1 SMP Debian 3.16.7-ckt25-2+deb8u3 (2016-07-02) 
machine    : x86_64 
nr_cpus    : 16 
max_cpu_id    : 47 
nr_nodes    : 1 
cores_per_socket  : 8 
threads_per_core  : 2 
cpu_mhz    : 2500 
hw_caps    : bfebfbff:2c100800:00000000:00007f00:77bee3ff:00000000:00000001:00000281 
virt_caps    : hvm hvm_directio 
total_memory   : 32704 
free_memory   : 17945 
sharing_freed_memory : 0 
sharing_used_memory : 0 
outstanding_claims  : 0 
free_cpus    : 0 
xen_major    : 4 
xen_minor    : 6 
xen_extra    : .0 
xen_version   : 4.6.0 
xen_caps    : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64 
xen_scheduler   : credit 
xen_pagesize   : 4096 
platform_params  : virt_start=0xffff800000000000 
xen_changeset   : 
xen_commandline  : placeholder dom0_mem=1024M,max:1024M dom0_max_vcpus=1 dom0_vcpus_pin no-real-mode edd=off 
cc_compiler   : gcc (Debian 5.3.1-8) 5.3.1 20160205 
cc_compile_by   : ijc 
cc_compile_domain  : debian.org 
cc_compile_date  : Tue Feb 9 17:46:27 UTC 2016 
xend_config_format  : 4 

Образец DOMU конфигурации:

name="VM1" 
uuid="91f4c306-101b-431b-bf73-2146b2a137fb" 
vcpus=2 
memory=2048 
disk = [ "phy:/dev/vg1/centos,xvda2,w", 
    "file:/path/folder/images/CentOS-7-x86_64-Minimal-511.iso,xvdb:cdrom,r" ] 
builder = "hvm" 
boot = "dc" 
vnc = "1" 
vnclisten = "0.0.0.0" 
vncdisplay = "0" 
vncpasswd = "password" 
vga ="stdvga" 
videoram = 64 

Любые советы о том, как заставить VNC работать плавно и правильно, будет очень оценили!

ответ

0

Спасибо за рекомендацию. Оказалось, что у нас были смешанные версии Xen и его зависимости (некоторые 4.4, некоторые 4.6). Мы закончили удаление Xen и всех связанных пакетов и переустановку. Во время установки мы заметили, что установка xen-hypervisor-4.6-amd64 исходила из ретрансляции растяжения (ожидается), но его зависимости были получены из основного репо jessie с более старыми версиями (например, libxen-4.4 вместо libxen-4.6). Чтобы решить эту проблему, мы запустили apt-get -t stretch install xen-hypervisor-4.6-amd64 , который правильно установил все зависимости от растяжки, а после перезагрузки соединения VNC с HVM domU работали должным образом.

0

Попробуйте добавить GRUB_GFXPAYLOAD_LINUX="keep" или GRUB_GFXPAYLOAD_LINUX="640x480" (или другое разрешение) в /etc/default/grub на DomU, а затем запустить update-grub2 (на DomU) и перезагрузиться. Это помогло мне с той же ошибкой.

Смежные вопросы