Re: [vdsm] [Users] Resizing disks destroys contents
by Dan Kenigsberg
On Sat, Oct 12, 2013 at 12:27:02AM +0330, Mohsen Saeedi wrote:
> I have same problem too. I have one node as ovirt engine and as
> hypervisor too. I successfully upgrade our engine from 3.1 to 3.2 and then
> from 3.2 to 3.3 and everything is ok.
> then i upgrade our cluster version to 3.3 and then our datacenter to 3.3.
> I increase 1GB on virtual machine with 20GB thin disk and I receive
> success message on event and our disk increase to 21GB but after host
> reboot, i saw message that contains no bootable disk is available!!!
> then i try to install new os on that disk (Centos 6.4 minimal) and
> anaconda show the error on screen : No usable disks have found. I think
> disk corrupt after resizing.
> it was test VM but it's very if occur for real and functional VMs.
Yes, this is indeed a bad bad bug. It was inadvertantly fixed on the
master branch a while ago. Yesterday, we've backported the fix to
3.3.0.1
http://lists.ovirt.org/pipermail/users/2013-October/017018.html
Please avoid trying ovirt-3.3.0's new disk resize feature on file-based storage,
unless you upgrade to vdsm vdsm-4.12.1-4 first.
Dan.
10 years, 8 months
vdsm sync meeting - October 7th 2013
by Dan Kenigsberg
We had an unpleasant talk, hampered by statics and disconnection on
danken's side. Beyond the noises I've managed to recognize Yaniv, Toni,
Douglas, Danken, Ayal, Timothy, Yeela and Mooli. We've managed to discuss:
- vdsm-4.13.0 is tagged, with a know selinux issue on el6. Expect a new
seliux-policy solving it any time soon.
- All bugfixes should be backported to ovirt-3.3, so that we have a
stable and comfortable vdsm in ovirt-3.3.1. Risky changes and new
features should remain in master IMO.
- We incorporated a glusterfs requirement breaking rpm installaiton for
people. We should avoid that by posters notifying reviewers more
prominently and by having
http://jenkins.ovirt.org/job/vdsm_install_rpm_sanity_gerrit/
run on every patch that touches vdsm.spec.in.
David, could you make the adjustment to the job?
- We discussed feature negotiation: Toni and Dan liked the idea of
having vdsm expose a feature flags, to make it easier on Engine to
check if a certain feature is supported.
Ayal argues that this is useful only for capabilities that depend on
existence on lower level components. Sees little value in fine
feature granularity on vdsm side - versions is enough.
So the disputed question is only how many feature flags we should
have, and when to set them: statically or based on negotiation with
kernel/libvirt/gluster/what not.
- Unified network persistence patches are being merged into master
- Timothy is working on fixing
http://jenkins.ovirt.org/job/vdsm_verify_error_codes/lastBuild/console
(hopefully by introducing the new error codes to Engine)
I was dropped from the call, so please append with stuff that I've
missed. Sorry for the noise!
Dan.
10 years, 8 months
stale gerrit patches
by iheim@redhat.com
we have some very old gerrit patches.
I'm for abandoning patches which were not touched over 60 days (to begin
with, I think the number should actually be lower).
they can always be re-opened by any interested party post their closure.
i.e., looking at gerrit, the patch list should actually get attention,
and not be a few worth looking at, with a "lot of old patches"
thoughts?
Thanks,
Itamar
10 years, 8 months
supervdsmServer: Enable logging from multiprocessing library
by dgibson@redhat.com
At present, if the super vdsm server dies with an exception inside
Python's multiprocessing module, then it will not usually produce any
useful debugging output.
The multiprocessing module includes error logging using Python's logging
module, but it is not enabled by default. This patch enables the
logging and sets it to propagate to the supervdsmServer's root logger,
so it now defaults to producing logging and can be configured easily
from /etc/vdsm/svdsm.logger.conf.
Signed-off-by: David Gibson <david(a)gibson.dropbear.id.au>
---
vdsm/supervdsmServer | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/vdsm/supervdsmServer b/vdsm/supervdsmServer
index 40ec9df..43a408f 100755
--- a/vdsm/supervdsmServer
+++ b/vdsm/supervdsmServer
@@ -42,6 +42,7 @@ except:
log.warn("Could not init proper logging", exc_info=True)
from storage import fuser
+import multiprocessing
from multiprocessing import Pipe, Process
from gluster import listPublicFunctions
import storage.misc as misc
@@ -356,6 +357,9 @@ class _SuperVdsm(object):
def main(sockfile, pidfile=None):
log = logging.getLogger("SuperVdsm.Server")
+ # Wire up the multiprocessing logger
+ mlog = multiprocessing.get_logger()
+ mlog.propagate = 1
def bind(func):
def wrapper(_SuperVdsm, *args, **kwargs):
--
1.8.3.1
--
David Gibson <dgibson(a)redhat.com>
10 years, 8 months
vdsm-functional-tests (networking)
by asegurap@redhat.com
Hi,
For each new patchset you submit, if it touches any of the networking files
(vdsm/vm.py is not included as it is not really covered by the net func tests),
the whole functional tests will be triggered and run by jenkins.
Best regards,
Toni
10 years, 8 months