8:02 p.m.
Hi,
I've updated my oVirt engine and node from version 3.1.0-2 to the
more recent 3.1.0-4. As far as I can tell from the update log, the
engine update went fine by following these instructions:
https://www.rvanderlinden.net/wordpress/ovirt/engine-installation/engine-...
Now I'm unable to start a VM through the Admin Portal. It fails with
the following error message:
VM test_srv is down. Exit message: local variable 'volPath' referenced before
assignment.
What's wrong? It seems this message is related to this bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=843387
But apparently there is no solution.
What is the fix or workaround to get VMs working again?
Thanks
- Frank
8:39 p.m.
Hi Frank,
It looks like the same issue as in the bug,
the bug also references a Change-Id for a fix: I8ad50c3a3485812f57800bbe6b7318a90fe5b962
and you can also access this patch in the following link:
http://gerrit.ovirt.org/#/c/6794/2
Can you tell if the vdsm version installed on your host includes this patch?
(you can check under /usr/share/vdsm/clientIF.py).
If it's in there please send the full logs (engine+vdsm) and the bug might need to be
reopened,
otherwise you can just upgrade vdsm and hopefully it would solve the problem.
Regards,
Yeela
----- Original Message -----
From: "Frank Wall" <fwall(a)inotronic.de>
To: users(a)ovirt.org
Sent: Tuesday, January 8, 2013 7:02:50 PM
Subject: [Users] local variable 'volPath' referenced before assignment
Hi,
I've updated my oVirt engine and node from version 3.1.0-2 to the
more recent 3.1.0-4. As far as I can tell from the update log, the
engine update went fine by following these instructions:
https://www.rvanderlinden.net/wordpress/ovirt/engine-installation/engine-...
Now I'm unable to start a VM through the Admin Portal. It fails with
the following error message:
VM test_srv is down. Exit message: local variable 'volPath'
referenced before assignment.
What's wrong? It seems this message is related to this bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=843387
But apparently there is no solution.
What is the fix or workaround to get VMs working again?
Thanks
- Frank
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
7:54 p.m.
Hi Yeela,
On Tue, Jan 08, 2013 at 12:39:08PM -0500, Yeela Kaplan wrote:
Can you tell if the vdsm version installed on your host includes this
patch?
(you can check under /usr/share/vdsm/clientIF.py).
well, I'm not sure if this patch is included in my version, but according to
the output of diff is seems that it is actually NOT included:
--- clientIF_new-617e328d546570a94e4357b3802a062e6a7610cb.py 2012-08-08
14:52:28.000000000 +0200
+++ /usr/share/vdsm/clientIF.py 2012-10-04 22:46:42.000000000 +0200
[...skipping other differences...]
@@ -289,15 +255,11 @@
if drive['device'] == 'cdrom':
volPath = supervdsm.getProxy().mkIsoFs(vmId, files)
elif drive['device'] == 'floppy':
- volPath = \
- supervdsm.getProxy().mkFloppyFs(vmId, files)
+ volPath = supervdsm.getProxy().mkFloppyFs(vmId, files)
- elif "path" in drive:
+ elif drive.has_key("path"):
volPath = drive['path']
- else:
- raise vm.VolumeError(drive)
-
# For BC sake: None as argument
elif not drive:
volPath = drive
Apparently the part from the fix with "raise vm.VolumeError(drive)" is missing,
although I'm running a newer version of vdsm. According to the bug report at
https://bugzilla.redhat.com/show_bug.cgi?id=843387
the fix should be in vdsm-4.9.6-29.0 (RHEL6), while I'm running
vdsm-4.10.0-10.fc17.x86_64:
# rpm -q --whatprovides /usr/share/vdsm/clientIF.py
vdsm-4.10.0-10.fc17.x86_64
I must admit that this is oVirt on FC17 and not RHEV on RHEL, so this may
explain the different versions of vdsm.
If it's in there please send the full logs (engine+vdsm) and the
bug might
need to be reopened, otherwise you can just upgrade vdsm and hopefully it
would solve the problem.
I've attached the full logs. It contains all log entries from activating
the ovirt node until trying to start the VM (both engine+vdsm).
Thanks
- Frank
7:59 p.m.
On Wed, Jan 09, 2013 at 05:54:22PM +0100, Frank Wall wrote:
I've attached the full logs. It contains all log entries from
activating
the ovirt node until trying to start the VM (both engine+vdsm).
The vdsm.log was missing/empty, so please find the required logs attached.
Thanks
- Frank
7:58 p.m.
----- Original Message -----
From: "Frank Wall" <fwall(a)inotronic.de>
To: users(a)ovirt.org
Sent: Wednesday, January 9, 2013 6:54:22 PM
Subject: Re: [Users] local variable 'volPath' referenced before assignment
Hi Yeela,
On Tue, Jan 08, 2013 at 12:39:08PM -0500, Yeela Kaplan wrote:
> Can you tell if the vdsm version installed on your host includes
> this patch?
> (you can check under /usr/share/vdsm/clientIF.py).
well, I'm not sure if this patch is included in my version, but
according to
the output of diff is seems that it is actually NOT included:
--- clientIF_new-617e328d546570a94e4357b3802a062e6a7610cb.py
2012-08-08 14:52:28.000000000 +0200
+++ /usr/share/vdsm/clientIF.py 2012-10-04 22:46:42.000000000 +0200
[...skipping other differences...]
@@ -289,15 +255,11 @@
if drive['device'] == 'cdrom':
volPath =
supervdsm.getProxy().mkIsoFs(vmId,
files)
elif drive['device'] == 'floppy':
- volPath = \
-
supervdsm.getProxy().mkFloppyFs(vmId,
files)
+ volPath =
supervdsm.getProxy().mkFloppyFs(vmId, files)
- elif "path" in drive:
+ elif drive.has_key("path"):
volPath = drive['path']
- else:
- raise vm.VolumeError(drive)
-
Frank, it looks like you don't have the patch inside your version of vdsm.
Please add it and see if it solves the problem.
# For BC sake: None as argument
elif not drive:
volPath = drive
Apparently the part from the fix with "raise vm.VolumeError(drive)"
is missing,
although I'm running a newer version of vdsm. According to the bug
report at
https://bugzilla.redhat.com/show_bug.cgi?id=843387
the fix should be in vdsm-4.9.6-29.0 (RHEL6), while I'm running
vdsm-4.10.0-10.fc17.x86_64:
# rpm -q --whatprovides /usr/share/vdsm/clientIF.py
vdsm-4.10.0-10.fc17.x86_64
I must admit that this is oVirt on FC17 and not RHEV on RHEL, so this
may
explain the different versions of vdsm.
> If it's in there please send the full logs (engine+vdsm) and the
> bug might
> need to be reopened, otherwise you can just upgrade vdsm and
> hopefully it
> would solve the problem.
I've attached the full logs. It contains all log entries from
activating
the ovirt node until trying to start the VM (both engine+vdsm).
Thanks
- Frank
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
4334
days inactive
4336
days old
4 comments
2 participants
participants (2)
-
Frank Wall -
Yeela Kaplan