8:10 a.m.
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.
4:45 a.m.
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.
7:29 a.m.
Dan Kenigsberg <danken(a)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.
1:10 a.m.
On Thu, Mar 31, 2016 at 02:29:38PM +0200, Milan Zamazal wrote:
Dan Kenigsberg <danken(a)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.
1:39 p.m.
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.
3:17 p.m.
On Sat, May 21, 2016 at 9:39 PM, Milan Zamazal <pdm(a)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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
4:33 p.m.
>>>> "NS" == Nir Soffer
<nsoffer(a)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.
3137
days inactive
3189
days old
6 comments
4 participants
participants (4)
-
Dan Kenigsberg -
Milan Zamazal -
Milan Zamazal -
Nir Soffer