Debian Bug report logs - #571159
libvirt-bin: qemu-kvm fails migration with messages in the VMs about failed disks.

Reply or subscribe to this bug.

Display info messages

Message #5 received at [email protected] (full text, mbox, reply):

From: Gerasimos Melissaratos <[email protected]>

To: Debian Bug Tracking System <[email protected]>

Subject: libvirt-bin: qemu-kvm fails migration with messages in the VMs about failed disks.

Date: Wed, 24 Feb 2010 00:05:38 +0200

Package: libvirt-bin
Version: 0.7.6-2
Severity: important



When two libvirt/qemu servers (say, A and B) share and NFS server, migrating a VM form A to B fails, barring access to the disk image from server B. When the VM boots on server A, it sets uid/gid on the VM disk image to libvirt-qemu:kvm. During the migration process (initiated through virt-manager) the image acquires momentarily libvirt-qemu:kvm uid/gid on server B, but then it reverts to root:root and messages about failed disk access are printed on the screen of the running VM (normal, since the image gets root:root ownership). In order to migrate the image, I have to shut down the VM on server A and boot it again on server B, beating the whole idea of migration. Wether I migrate from A->B or B->A makes no difference.



-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-trunk-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=el_GR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages libvirt-bin depends on:
ii  adduser           3.112                  add and remove users and groups
ii  libavahi-client3  0.6.25-3               Avahi client library
ii  libavahi-common3  0.6.25-3               Avahi common library
ii  libc6             2.10.2-6               Embedded GNU C Library: Shared lib
ii  libcap-ng0        0.6.2-4+b1             An alternate posix capabilities li
ii  libdevmapper1.02. 2:1.02.39-1            The Linux Kernel Device Mapper use
ii  libgcrypt11       1.4.5-2                LGPL Crypto library - runtime libr
ii  libgnutls26       2.8.5-2                the GNU TLS library - runtime libr
ii  libparted1.8-12   1.8.8.git.2009.07.19-5 The GNU Parted disk partitioning s
ii  libpciaccess0     0.11.0-1               Generic PCI access library for X
ii  libreadline6      6.1-1                  GNU readline and history libraries
ii  libsasl2-2        2.1.23.dfsg1-5         Cyrus SASL - authentication abstra
ii  libudev0          151-2                  libudev shared library
ii  libuuid1          2.16.2-0               Universally Unique ID library
ii  libvirt0          0.7.6-2                library for interfacing with diffe
ii  libxenstore3.0    3.4.2-2                Xenstore communications library fo
ii  libxml2           2.7.6.dfsg-2+b1        GNOME XML library
ii  logrotate         3.7.8-4                Log rotation utility

Versions of packages libvirt-bin recommends:
ii  bridge-utils                  1.4-5      Utilities for configuring the Linu
ii  dnsmasq-base                  2.52-1     A small caching DNS proxy and DHCP
ii  iptables                      1.4.6-2    administration tools for packet fi
ii  netcat-openbsd                1.89-3     TCP/IP swiss army knife
ii  qemu                          0.11.1-2   fast processor emulator

Versions of packages libvirt-bin suggests:
ii  policykit-1                   0.96-1     framework for managing administrat

-- no debconf information

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Message #8 received at [email protected] (full text, mbox, reply):

From: Guido Günther <[email protected]>

To: [email protected]

Subject: Possible workaround?

Date: Mon, 8 Mar 2010 18:07:35 +0100

Hi,
It seems there's a problem with the first instance restoring privileges
_after_ the second one starts. Could you try setting user and group to
"root" in /etc/libvirt/qemu.conf? This should work around the problem.
Cheers,
 -- Guido

Message #13 received at [email protected] (full text, mbox, reply):

From: MELISSARATOS Gerasimos <[email protected]>

To: Guido Günther <[email protected]>, [email protected]

Subject: Re: Bug#571159: Possible workaround?

Date: Thu, 11 Mar 2010 12:01:33 +0200 (EET)

Was going to try it, but now, after upgrading to
ii  libvirt-bin                         0.7.7-1                    the programs for the libvirt library
ii  libvirt0                            0.7.7-1                    library for interfacing with different virtu
ii  qemu-kvm                            0.12.3+dfsg-3              Full virtualization on x86 hardware

things took an ugly turn, and I cannot even connect to the console of the virtual machine. Something seems to has broken with TLS authentication. So, I'm putting migration on the back burner for a few days to see what's going on with vnc and tls.

Thanks,
Gerasimos


----- Αρχικό Μήνυμα -----
Από: "Guido Günther" <[email protected]>
Προς: [email protected]
Απεσταλμένα: Monday, March 8, 2010 7:07:35 PM GMT +02:00 Harare / Pretoria
Θέμα: Bug#571159: Possible workaround?

Hi,
It seems there's a problem with the first instance restoring privileges
_after_ the second one starts. Could you try setting user and group to
"root" in /etc/libvirt/qemu.conf? This should work around the problem.
Cheers,
 -- Guido



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Message #18 received at [email protected] (full text, mbox, reply):

From: MELISSARATOS Gerasimos <[email protected]>

To: Guido Günther <[email protected]>, [email protected]

Subject: Re: Bug#571159: Possible workaround?

Date: Wed, 24 Mar 2010 23:18:43 +0200 (EET)

As mentioned, I was going to look into the vnc+tls problem, and this is what I found. When I run "strace virt-viewer -v --debug -c qemu+tls://hostname/system slack", at the end I get the following output:

write(1, "** (virt-viewer:4703): DEBUG: Go"..., 77** (virt-viewer:4703): DEBUG: Got VNC credential request for 1 credential(s)
) = 77
getuid()                                = 1000
open("/etc/passwd", O_RDONLY|O_CLOEXEC) = 10
lseek(10, 0, SEEK_CUR)                  = 0
fstat(10, {st_mode=S_IFREG|0644, st_size=2501, ...}) = 0
mmap(NULL, 2501, PROT_READ, MAP_SHARED, 10, 0) = 0x7fbf71ec7000
lseek(10, 2501, SEEK_SET)               = 2501
munmap(0x7fbf71ec7000, 2501)            = 0
close(10)                               = 0
stat("(null)/CA/cacert.pem", 0x7fffe54c5c70) = -1 ENOENT (No such file or directory)
stat("(null)/CA/cacert.pem", 0x7fffe54c5c70) = -1 ENOENT (No such file or directory)
write(1, "** (virt-viewer:4703): DEBUG: Fa"..., 62** (virt-viewer:4703): DEBUG: Failed to set credential type 2
) = 62
close(9)                                = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
rt_sigprocmask(SIG_SETMASK, [], [], 8)  = 0
open("/usr/share/locale/en_US/LC_MESSAGES/libgnutls.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en/LC_MESSAGES/libgnutls.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
sendto(-1, "\25\3\2\0\2\1\0", 7, 0, NULL, 0) = -1 EBADF (Bad file descriptor)
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
rt_sigprocmask(SIG_SETMASK, [], [], 8)  = 0
read(3, 0x249a764, 4096)                = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=3, events=POLLIN}, {fd=5, events=POLLIN}], 2, 0) = 0 (Timeout)
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
rt_sigprocmask(SIG_SETMASK, [], [], 8)  = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}])
writev(3, [{"\22\0\v\0\3\0\0\4/\1\0\0X\1\0\0\10\4\5\0\24\0\0\0(null) -"..., 180}, {NULL, 0}, {"", 0}], 3) = 180
poll([{fd=3, events=POLLIN}], 1, -1)    = 1 ([{fd=3, revents=POLLIN}])
read(3, "\34\0&\1\3\0\0\4/\1\0\0\0[\2725\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) = 160
read(3, 0x249a764, 4096)                = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}])
writev(3, [{"+\0\1\0", 4}, {NULL, 0}, {"", 0}], 3) = 4
poll([{fd=3, events=POLLIN}], 1, -1)    = 1 ([{fd=3, revents=POLLIN}])
read(3, "\1\2+\1\0\0\0\0\4\0\0\4\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 4096) = 32
read(3, 0x249a764, 4096)                = -1 EAGAIN (Resource temporarily unavailable)
close(11)                               = 0
exit_group(0)                           = ?


I notice the stat lines, they have this "(null)/CA/cacert.pem", when all other stat lines have no "null". From then on it's all error and failure. Hope this helps a bit.

Bye, Gerasimos Melissaratos

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Message #21 received at [email protected] (full text, mbox, reply):

From: Guido Günther <[email protected]>

To: [email protected]

Subject: Please file a different bug

Date: Sun, 28 Mar 2010 19:47:52 +0200

Hi Gerasimos,
please file a different bug about your gtk-vnc problem including version
information for virt-viewer and gtk-vnc. So we can handle that first.
Thanks,
 -- Guido

Message #28 received at [email protected] (full text, mbox, reply):

From: intrigeri <[email protected]>

To: [email protected], [email protected]

Subject: Re: Bug#571159: libvirt-bin: crash at startup

Date: Mon, 13 Oct 2014 11:32:36 +0200

Hi,

Guido Günther wrote (28 Mar 2010 17:47:52 GMT) :
> please file a different bug about your gtk-vnc problem including version
> information for virt-viewer and gtk-vnc. So we can handle that first.

What's the status on this front? Is the bug still reproducible on
current Debian stable or testing/sid? Was the bug against
gtk-vnc filed?

Cheers,
--
intrigeri

Send a report that this bug log contains spam.