Description of problem: The top-level /rhev dir should be moved to some subdir, i.e. /run/vdsmd/mounts or /var/lib/vdsm or whatever - to better suite the FHS and make the adoption to all kind if image related delivery methods easier (Node, containers, ). Often these kind of tools are already handling well known paths in an appropriate way, and no special handling for /rhev is needed.
This will break compatibility with old hypervisors - migrating a vm from new host using /var/run/vdsm/storage to old host using /rhev/data-center will fail, since the vm is looking for its disks in /rhev/data-center.
(In reply to Nir Soffer from comment #2) > This will break compatibility with old hypervisors - migrating a vm from > new host using /var/run/vdsm/storage to old host using /rhev/data-center > will fail, since the vm is looking for its disks in /rhev/data-center. Worth considering when designing RHEV 4.0.
Please consider to raise the priority again, this is an important structural change for Node.
Any update on this one?
*** Bug 1369102 has been marked as a duplicate of this bug. ***
please notice "Bug 1369102 - vdsm violates FHS with /rhev" . Can we raise priority?
Why do we need to raise the priority? what is the benefit of this to users?
Just my 2ct: Some systems like ostree assume that the OS is following the FHS, non-FHS dirs like /rhev mark an exception and can not easily be handled correctly. Thus to better integrate with this it makes sense to move the dir to an FHS compliant directory.
(In reply to Fabian Deutsch from comment #9) > Just my 2ct: Some systems like ostree assume that the OS is following the > FHS, non-FHS dirs like /rhev mark an exception and can not easily be handled > correctly. /rhev/data-center is a temporary directory used for mounting storage domains and file-like directory structure for block storage domains. The directory will be created automatically by vdsm when a host is added to a data center on engine. We don't need any handling from the OS. Do you know of any real issue with this directory affecting users?
When I was trying vdsm in an ostree tree, / was immutable (chattr +i /) which prevented the creation of /rhev
(In reply to Fabian Deutsch from comment #11) > When I was trying vdsm in an ostree tree, / was immutable (chattr +i /) > which prevented the creation of /rhev Looks like an ostree bug, breaking compatibility with existing packages. We can easily fix this by making / mutable during installation, since we own the machine :-)
:) Yes - That#s an easy thing to do. Otherwise we can try to comply with the FHS, because other systems like ostree make the same assumptions - that a package is following the FHS, this would allow us to adopt vdsm quicker to other systems - which also include containers.
(In reply to Nir Soffer from comment #10) > We don't need any handling from the OS. Do you know of any real issue with > this > directory affecting users? The ostree example is a good one — having standards lets packages like ostree make assumptions that will work across various software, rather than having to do a bunch of special cases. That can be extended across a lot of other user-focused cases as well: backups, disk/partition sizing, etc. Additionally, if one package starts doing it without going through the documented exception process, it's an invitation for all sorts of other packages to do it, and after not too long we have no standard at all.
I think we can do this: 4.0 Add --enable-fhs configuration, using standard location for /rhev/data-center this will allow packaging vdsm in platforms that require this, or new platforms they have no users yet, so backward compatibility is not required. This will be considered experimental and unsupported. On upstream and RHEL builds we will continue to use /rhev/data-center. 4.1 Provide an easy way to migrate vms from old system using /rhev/data-center to new system using fhs compliant location. Migrating vms from new system (using fhs) to old system will not be possible. 5.0 Make fhs the default, do not support migration from old versions. Dan, what do you think?
Sounds like a sound plan.
After discussion with Dan and Allon, we will need a better solution. Users typically upgrade one or few hypervisors at a time, and expect that vms can migrate to any hypervisor using the same cluster version, regardless of vdsm version. Any vdsm version supporting cluster versions 3.6 and 4.0 must be able to migrate vm to and from any other vdsm version supporting same cluster versions. To migrate vms to a host with different data-center location, the vm xml must be modified on the source host using libvirt pre migration hook. Since this feature is not available in ovirt 4.0, we cannot support FHS compliant data-center on any setup running ovirt-3.6 and 4.0 hypervisors. Since we don't support mixing hypervisors of different platforms, this is not an issue for new platforms like Debian, using FHS compliant configuration: https://anonscm.debian.org/git/collab-maint/vdsm.git/tree/debian/patches/paths.patch On Fedora it seems that we have no choice but to break backward compatibility: https://bugzilla.redhat.com/show_bug.cgi?id=1361659#c23 So we will use same setup as in Debian (/run/vdsm). Being able to upgrade to ovirt 4.0 with some vm downtime is better then having no upgrade. Fedora users using that want to avoid the downtime should install the upstream builds from http://resources.ovirt.org/pub/ovirt-4.0 - they will be backward compatible and use /rhev.
What is the status? Should this be MODIFIED? What is the next step here?
(In reply to Yaniv Dary from comment #18) > What is the status? Should this be MODIFIED? > What is the next step here? No, we cannot move /rhev, this will break compatibility with existing installations. We have now a configure option enabled in the fedora build, so on fedora built vdsm, /rhev/data-center moved to /run/vdsm/data-center. But on ovirt, centos and rhel builds, we still use /rhev/data-center until we find a way to support migration of vms between hosts with different data-center locations.
Seems risky with limited benefit. Closing,
Yaniv, There is plenty of benefit, not the least of which is that you're no longer polluting the main filesystem tree in an unexpected fashion, so things like system backups can leverage the relationships and roles of the regular FHS to properly back up data. Moving the directory would also make it possible for oVirt to be part of Fedora itself, as well as restore compatibility with oVirt.org oVirt, Debian oVirt, and other builds derived from that branch (where they moved it due to FHS incompatibility). Generally speaking, the /rhev path should have never been allowed to begin with. It should *not* be difficult to move the directory. You could even check for /rhev on upgrade and just move it and symlink it back or something. That way existing installs using /rhev work, while new installs that don't use /rhev would work too.
This bug didn't get any attention for a while, we didn't have the capacity to make any progress. If you deeply care about it or want to work on it please assign/target accordingly
ok, closing. Please reopen if still relevant/you want to work on it.