[Users] Migration issues with ovirt 3.3
Hi, I'm running ovirt-engine 3.3 in a server with fedora 19, also two host with fedora 19 running vdsm and gluster. I'm using the repositories like it say's here: http://www.ovirt.org/OVirt_3.3_TestDay with enable the [ovirt-beta] & [ovirt-stable] repos and disable the [ovirt-nightly] repo. I've configured a datacenter with glusterfs active an the two Host. I've installed a VM and when I do a migration it fails with the message *"VM pfSense1 is down. Exit message: 'iface'."* and the VM reboots. Also if i try to make an snapshot the VM with the Save memory it fails with the message *"VM pfSense1 is down. Exit message: Lost connection with qemu process."* If I make an snapshot without the Save Memory checked it works. I've tried to restart the libvirtd service but it's still happening. Before this I've tried the cluster with NFS storage and have problems with migration too, but the error messages were differents. Now I'm trying with gluster because this is what i want to use. Could you give me any hint about this? Regards! Emiliano
On Mon, Sep 23, 2013 at 12:15:04PM -0300, emitor@gmail.com wrote:
Hi,
I'm running ovirt-engine 3.3 in a server with fedora 19, also two host with fedora 19 running vdsm and gluster. I'm using the repositories like it say's here: http://www.ovirt.org/OVirt_3.3_TestDay with enable the [ovirt-beta] & [ovirt-stable] repos and disable the [ovirt-nightly] repo.
I've configured a datacenter with glusterfs active an the two Host. I've installed a VM and when I do a migration it fails with the message *"VM pfSense1 is down. Exit message: 'iface'."* and the VM reboots.
Could you sare vdsm.log from source and destination?
Also if i try to make an snapshot the VM with the Save memory it fails with the message *"VM pfSense1 is down. Exit message: Lost connection with qemu process."* If I make an snapshot without the Save Memory checked it works.
Here, beyond vdsm.log, I would ask to see /etc/libvirt/qemu/pfSense1.log to understand why qemu crashed. Please report the version of your qemu-kcm and kernel.
I've tried to restart the libvirtd service but it's still happening.
Would you make sure you upgrade to newest libvirt? We had some annoying bugs resolved by a recent upgrade there.
Before this I've tried the cluster with NFS storage and have problems with migration too, but the error messages were differents. Now I'm trying with gluster because this is what i want to use.
Could you give me any hint about this?
Thanks for your answer Dan! Yesterday was talking with an user in the IRC and gave me the hint to upgrade the libvirt to the 1.1.2 after trying in his implementation the live migration successfully. I've upgraded the libvirt but I'm still having the issue. I send to you the logs that you asked to me and the information bellow: OS Version: Fedora - 19 - 3 Kernel Version: 3.11.1 - 200.fc19.x86_64 KVM Version: 1.4.2 - 9.fc19 LIBVIRT Version: libvirt-1.1.2-1.fc19 VDSM Version: vdsm-4.12.1-2.fc19 SPICE Version: 0.12.4 - 1.fc19 iSCSI Initiator Name: iqn.1994-05.com.redhat:d990cf85cdeb SPM Priority: Medium Active VMs: 1 CPU Name: Intel Westmere Family CPU Type: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz CPU Sockets: 1 CPU Cores per Socket: 4 CPU Threads per Core: 2 (SMT Enabled) Physical Memory: 12007 MB total, 2762 MB used, 9245 MB free Swap Size: 15999 MB total, 0 MB used, 15999 MB free Shared Memory: 0% Max free Memory for scheduling new VMs: 15511.5 MB Memory Page Sharing: Inactive Automatic Large Pages: Always (Both hypervisors have the same hardware and software version) I'm going to keep trying some things becouse something must get messed up because now i have a VM with Debian that doesn't start giving me the error "Failed to run VM debian on Host ovirt1." and "Failed to run VM debian on Host ovirt2." Anyway I'll wait for your answer. Very Regards! Emiliano 2013/9/24 Dan Kenigsberg <danken@redhat.com>
On Mon, Sep 23, 2013 at 12:15:04PM -0300, emitor@gmail.com wrote:
Hi,
I'm running ovirt-engine 3.3 in a server with fedora 19, also two host with fedora 19 running vdsm and gluster. I'm using the repositories like it say's here: http://www.ovirt.org/OVirt_3.3_TestDay with enable the [ovirt-beta] & [ovirt-stable] repos and disable the [ovirt-nightly] repo.
I've configured a datacenter with glusterfs active an the two Host. I've installed a VM and when I do a migration it fails with the message *"VM pfSense1 is down. Exit message: 'iface'."* and the VM reboots.
Could you sare vdsm.log from source and destination?
Also if i try to make an snapshot the VM with the Save memory it fails with the message *"VM pfSense1 is down. Exit message: Lost connection with qemu process."* If I make an snapshot without the Save Memory checked it works.
Here, beyond vdsm.log, I would ask to see /etc/libvirt/qemu/pfSense1.log to understand why qemu crashed. Please report the version of your qemu-kcm and kernel.
I've tried to restart the libvirtd service but it's still happening.
Would you make sure you upgrade to newest libvirt? We had some annoying bugs resolved by a recent upgrade there.
Before this I've tried the cluster with NFS storage and have problems
with
migration too, but the error messages were differents. Now I'm trying with gluster because this is what i want to use.
Could you give me any hint about this?
-- *Emiliano Tortorella* +598 98941176 emitor@gmail.com
On Tue, Sep 24, 2013 at 02:41:58PM -0300, emitor@gmail.com wrote:
Thanks for your answer Dan!
Yesterday was talking with an user in the IRC and gave me the hint to upgrade the libvirt to the 1.1.2 after trying in his implementation the live migration successfully.
I've upgraded the libvirt but I'm still having the issue. I send to you the logs that you asked to me and the information bellow: OS Version: Fedora - 19 - 3 Kernel Version: 3.11.1 - 200.fc19.x86_64 KVM Version: 1.4.2 - 9.fc19 LIBVIRT Version: libvirt-1.1.2-1.fc19 VDSM Version: vdsm-4.12.1-2.fc19 SPICE Version: 0.12.4 - 1.fc19 iSCSI Initiator Name: iqn.1994-05.com.redhat:d990cf85cdeb SPM Priority: Medium Active VMs: 1 CPU Name: Intel Westmere Family CPU Type: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz CPU Sockets: 1 CPU Cores per Socket: 4 CPU Threads per Core: 2 (SMT Enabled) Physical Memory: 12007 MB total, 2762 MB used, 9245 MB free Swap Size: 15999 MB total, 0 MB used, 15999 MB free Shared Memory: 0% Max free Memory for scheduling new VMs: 15511.5 MB Memory Page Sharing: Inactive Automatic Large Pages: Always
(Both hypervisors have the same hardware and software version)
I'm going to keep trying some things becouse something must get messed up because now i have a VM with Debian that doesn't start giving me the error "Failed to run VM debian on Host ovirt1." and "Failed to run VM debian on Host ovirt2."
Anyway I'll wait for your answer. Very Regards! Emiliano
Your destination Vdsm has vmId=`1f7e60c7-51cb-469a-8016-58a5837f3316`::The vm start process failed Traceback (most recent call last): File "/usr/share/vdsm/vm.py", line 2022, in _startUnderlyingVm self._run() File "/usr/share/vdsm/vm.py", line 2819, in _run devices = self.buildConfDevices() File "/usr/share/vdsm/vm.py", line 1839, in buildConfDevices devices = self.getConfDevices() File "/usr/share/vdsm/vm.py", line 1806, in getConfDevices self.normalizeDrivesIndices(devices[DISK_DEVICES]) File "/usr/share/vdsm/vm.py", line 1990, in normalizeDrivesIndices if drv['iface'] not in self._usedIndices: KeyError: 'iface' Which looks just like Bug 1011472 - [vdsm] cannot recover VM upon vdsm restart after a disk has been hot plugged to it. Could it be that you have hot-plugged a disk to your VM at the source host? Somehow, Vdsm forgets to keep the 'iface' element passed from Engine for the hot-plugged disk. Dan.
participants (2)
-
Dan Kenigsberg -
emitor＠gmail.com