Progress report on Vdsm Debian packaging
I made progress with Debian packaging of Vdsm. We have all the supporting packages (cpopen, ioprocess, mom, pthreading, safelease, sanlock) in Debian now. I took over maintenance of sanlock Debian package, updated it and made a lot of fixes, including preparing the previously unavailable python-sanlock package. As for Vdsm itself, the package can be installed now and Vdsm can be started. It doesn't work with Engine, which is no big surprise. We can't simply reinstall a Debian host from Engine, so we need to find some way how to initialize the host properly. And it's likely there are distribution specific pieces inside Vdsm and elsewhere. All the package sources, including not yet uploaded Vdsm package, are available on http://git.debian.org . How you can help: - Obviously, we need to make Vdsm hosts working, so any help in this area is welcome. - Reviewing and testing Vdsm Debian package (without actually using it) is also very helpful, I'm sure there are things to fix or improve. - There are some Lintian warnings in the packages, fixing them would be nice. - We should also review Debian patches in the packages, decide what should be changed upstream and report it. - You can help with anything else you consider useful.
On Wed, Mar 30, 2016 at 03:10:52PM +0200, Milan Zamazal wrote:
I made progress with Debian packaging of Vdsm. We have all the supporting packages (cpopen, ioprocess, mom, pthreading, safelease, sanlock) in Debian now. I took over maintenance of sanlock Debian package, updated it and made a lot of fixes, including preparing the previously unavailable python-sanlock package.
Thanks for your effort. I think that porting Vdsm and its dependencies would help make the code cleaner and more robust.
As for Vdsm itself, the package can be installed now and Vdsm can be started. It doesn't work with Engine, which is no big surprise. We can't simply reinstall a Debian host from Engine, so we need to find some way how to initialize the host properly.
Sorry I do not understand what's currently breaking. Can you add a debian host to Engine? Does it show as up? Anything dubious in vdsm.log?
And it's likely there are distribution specific pieces inside Vdsm and elsewhere.
Of course there are. But we'd like to to find an kill them, one at a time.
All the package sources, including not yet uploaded Vdsm package, are available on http://git.debian.org .
How you can help:
- Obviously, we need to make Vdsm hosts working, so any help in this area is welcome.
- Reviewing and testing Vdsm Debian package (without actually using it) is also very helpful, I'm sure there are things to fix or improve.
- There are some Lintian warnings in the packages, fixing them would be nice.
- We should also review Debian patches in the packages, decide what should be changed upstream and report it.
- You can help with anything else you consider useful.
Dan Kenigsberg <danken@redhat.com> writes:
Sorry I do not understand what's currently breaking. Can you add a debian host to Engine?
No.
Does it show as up? Anything dubious in vdsm.log?
There are more error messages in vdsm.log and Engine, like unknown Vdsm version (it checks for `vdsmd' package instead of `vdsm'), missing ovs-vsctl (perhaps missing dependency), missing ovirtmgmt interface (due to the missing Open vSwitch?), low disk space in /run (it's tmpfs), etc. It needs polishing and I'm curious whether it will work afterwards or not.
On Thu, Mar 31, 2016 at 02:29:38PM +0200, Milan Zamazal wrote:
Dan Kenigsberg <danken@redhat.com> writes:
Sorry I do not understand what's currently breaking. Can you add a debian host to Engine?
No.
Does it show as up? Anything dubious in vdsm.log?
There are more error messages in vdsm.log and Engine, like unknown Vdsm version (it checks for `vdsmd' package instead of `vdsm'), missing ovs-vsctl (perhaps missing dependency), missing ovirtmgmt interface (due to the missing Open vSwitch?), low disk space in /run (it's tmpfs), etc. It needs polishing and I'm curious whether it will work afterwards or not.
ovs-vsctl should be required only by the (optional) vdsm-hook-ovs package. I know for sure that setup network would not work out of the box, but much like you, I'd like to know what else fails.
It should be now possible to connect Debian hosts to Engine, although not instantly (see below). You can start experimenting with VMs but don't expect much for now. If you'd like to play with fixing Vdsm on Debian, you can install the package as follows: - Use Debian testing (stretch) or unstable (sid). - Clone Vdsm Debian repository: $ git clone git://anonscm.debian.org/collab-maint/vdsm.git - Fetch the corresponding upstream source: $ wget http://resources.ovirt.org/pub/ovirt-3.6/src/vdsm/vdsm-4.17.23.2.tar.gz $ mv vdsm-4.17.23.2.tar.gz vdsm_4.17.23.2.orig.tar.gz - Install Vdsm build dependencies: # apt-get install debhelper dh-autoreconf dh-systemd python-dev \ python-nose python-cpopen python-libvirt python-netaddr \ python-pthreading python-pyinotify python-selinux python-six - Build the packages: $ cd vdsm $ dpkg-buildpackage - Install the packages # dpkg -i ../vdsm*.deb - Fix dependencies: # apt-get -f install Now there are some things that you must perform manually: - `kvm' group has dynamic gid on Debian, not 36. So you must create your own group with gid 36 and put the related users to it. This violates Debian policies but gid 36 is not allocated, so you can do it on your machine. If there are more reasons than just Vdsm to make kvm group static with gid 36, please tell me. - You must configure network interfaces manually, i.e. to create `ovirtmgmt' bridge in /etc/network/interfaces.d/ and disable your standard network interface (e.g. eth0) in /etc/network/interfaces.d. See `man interfaces' and `man bridge-utils-interfaces' for details. Alternatively, you can experiment with `net_configurator' Vdsm configuration option. - You must also manually configure vdsm-ovirtmgmt network interface in libvirt. If you're lucky, you should be able to start Vdsm now with systemctl and connect the host to Engine. Then it may be possible to create and start very simple VMs, but you probably won't be able to do much more with them (like connecting to their displays or powering them off). Any fixes are welcome.
On Sat, May 21, 2016 at 9:39 PM, Milan Zamazal <pdm@zamazal.org> wrote:
It should be now possible to connect Debian hosts to Engine, although not instantly (see below). You can start experimenting with VMs but don't expect much for now.
If you'd like to play with fixing Vdsm on Debian, you can install the package as follows:
- Use Debian testing (stretch) or unstable (sid).
- Clone Vdsm Debian repository:
$ git clone git://anonscm.debian.org/collab-maint/vdsm.git
- Fetch the corresponding upstream source:
$ wget http://resources.ovirt.org/pub/ovirt-3.6/src/vdsm/vdsm-4.17.23.2.tar.gz $ mv vdsm-4.17.23.2.tar.gz vdsm_4.17.23.2.orig.tar.gz
- Install Vdsm build dependencies:
# apt-get install debhelper dh-autoreconf dh-systemd python-dev \ python-nose python-cpopen python-libvirt python-netaddr \ python-pthreading python-pyinotify python-selinux python-six
- Build the packages:
$ cd vdsm $ dpkg-buildpackage
- Install the packages
# dpkg -i ../vdsm*.deb
- Fix dependencies:
# apt-get -f install
Now there are some things that you must perform manually:
- `kvm' group has dynamic gid on Debian, not 36. So you must create your own group with gid 36 and put the related users to it. This violates Debian policies but gid 36 is not allocated, so you can do it on your machine. If there are more reasons than just Vdsm to make kvm group static with gid 36, please tell me.
The actual number should not matter, the code should use the symbolic names and resolve the number using the pwd and grp modules. There is an issue with existing storage - if you want to connect debian host to storage domain created with another system, you must match your host configuration to the storage permissions. You can change the storage permissions, but this will make it incompatible with other systems. Nir
- You must configure network interfaces manually, i.e. to create `ovirtmgmt' bridge in /etc/network/interfaces.d/ and disable your standard network interface (e.g. eth0) in /etc/network/interfaces.d. See `man interfaces' and `man bridge-utils-interfaces' for details. Alternatively, you can experiment with `net_configurator' Vdsm configuration option.
- You must also manually configure vdsm-ovirtmgmt network interface in libvirt.
If you're lucky, you should be able to start Vdsm now with systemctl and connect the host to Engine. Then it may be possible to create and start very simple VMs, but you probably won't be able to do much more with them (like connecting to their displays or powering them off). Any fixes are welcome.
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
"NS" == Nir Soffer <nsoffer@redhat.com> writes:
NS> There is an issue with existing storage - if you want to connect NS> debian host to storage domain created with another system, you NS> must match your host configuration to the storage NS> permissions. You can change the storage permissions, but this NS> will make it incompatible with other systems. And additionally `kvm' (or any other dynamically allocated) group may have different gid on different Debian hosts.
participants (4)
-
Dan Kenigsberg -
Milan Zamazal -
Milan Zamazal -
Nir Soffer