Hi list, in October 2014 I began to build libvirt for IPFire. This failed the first time and second but now I tried it the third time with a lot more knowledge and it works well.
So I have a running libvirt daemon on my IPFire (Arch is x86_64 works very well by the way) and want to ask if the project is interested that the libvirt package becomes an official addon. It could save a lot of work because everybody have the chance to install what he want in a virtual machine. Also, I think it is safer to put my owncloud into a virtual machine than to put is directly on my IPFire. Also, it could save energy because a home user has to run only one real computer. Otherwise, libvirt is one more security risk and it is possible to break out of a virtual machine and attack the host. So these are some security aspects, but in the moment, I think there are more benefits than disadvantages. But I would like to hear your opinions on this topic.
So what are the dependencies for libvirt and what have to be done on existing packages.
Hard dependencies
util-macros libpciaccess libyajl
nice to have ( increase the usability)
opus python-six python-pyparsing spice-protocol spice
These packages provide a protocol similar to vnc (http://www.spice-space.org/)
optional ( create errors on start up but nothing more)
pm-utils dmidecode
what have to be done on existing addons
nmap: update to the latest version (to have a ncat version which supports the -U options, this is required to communicate over a normal ssh session)
ebtables: create some links (libvirt search in the wrong directory for the binaries)
dnsmasq enable HAVE_DHCP HAVE_SCRIPT HAVE_TFTP but I have to check this again on i686 HAVE_SCRIPT is enough, in the moment I have not the time to test where the problem is, but I will do this in the next weeks.
So that is it. Now I am waiting for your opinion and what you think about this :-).
Regards Jonatan
Ps. I would maintain these packages if they become official packages. PSS. I use a new e-mail address because my old one is currently blocked by this server.
sounds very interesting, but I am a mere ipfire user so I can not really judge the implications robert
On 19.03.2016 09:42, Jonatan Schlag wrote:
Hi list, in October 2014 I began to build libvirt for IPFire. This failed the first time and second but now I tried it the third time with a lot more knowledge and it works well.
So I have a running libvirt daemon on my IPFire (Arch is x86_64 works very well by the way) and want to ask if the project is interested that the libvirt package becomes an official addon. It could save a lot of work because everybody have the chance to install what he want in a virtual machine. Also, I think it is safer to put my owncloud into a virtual machine than to put is directly on my IPFire. Also, it could save energy because a home user has to run only one real computer. Otherwise, libvirt is one more security risk and it is possible to break out of a virtual machine and attack the host. So these are some security aspects, but in the moment, I think there are more benefits than disadvantages. But I would like to hear your opinions on this topic.
So what are the dependencies for libvirt and what have to be done on existing packages.
*Hard dependencies*
util-macros libpciaccess libyajl
*nice to have ( increase the usability)*
opus python-six python-pyparsing spice-protocol spice
These packages provide a protocol similar to vnc (http://www.spice-space.org/)
*optional ( create errors on start up but nothing more)*
pm-utils dmidecode
*what have to be done on existing addons*
nmap: update to the latest version (to have a ncat version which supports the -U options, this is required to communicate over a normal ssh session)
ebtables: create some links (libvirt search in the wrong directory for the binaries)
dnsmasq enable HAVE_DHCP HAVE_SCRIPT HAVE_TFTP but I have to check this again on i686 HAVE_SCRIPT is enough, in the moment I have not the time to test where the problem is, but I will do this in the next weeks.
So that is it. Now I am waiting for your opinion and what you think about this :-).
Regards Jonatan
Ps. I would maintain these packages if they become official packages. PSS. I use a new e-mail address because my old one is currently blocked by this server.
Hi,
thanks for getting in touch.
On Sat, 2016-03-19 at 09:42 +0100, Jonatan Schlag wrote:
Hi list, in October 2014 I began to build libvirt for IPFire. This failed the first time and second but now I tried it the third time with a lot more knowledge and it works well.
This is indeed something I would personally like to see in IPFire. Although I have many reasons why this is a bad idea...
So I have a running libvirt daemon on my IPFire (Arch is x86_64 works very well by the way) and want to ask if the project is interested that the libvirt package becomes an official addon.
It must be an add-on so that users do not have to install it if they don't wish to do so and to reduce attack surface.
It could save a lot of work because everybody have the chance to install what he want in a virtual machine. Also, I think it is safer to put my owncloud into a virtual machine than to put is directly on my IPFire. Also, it could save energy because a home user has to run only one real computer.
It is probably not more secure to run a KVM machine. Breaking out of that is easy enough. However, I would also like to see some things installed on a different system instead of on IPFire itself. Just because I think that there are better distributions out there to host owncloud and similar things. It will also allow to migrate this functionality from a physical machine to IPFire or from IPFire to a physcial machine later.
Otherwise, libvirt is one more security risk and it is possible to break out of a virtual machine and attack the host. So these are some security aspects, but in the moment, I think there are more benefits than disadvantages. But I would like to hear your opinions on this topic.
So what are the dependencies for libvirt and what have to be done on existing packages.
Hard dependencies
util-macros libpciaccess libyajl
nice to have ( increase the usability)
opus python-six python-pyparsing spice-protocol spice
These packages provide a protocol similar to vnc (http://www.spice-space.org/)
These look okay. Basically anything that is free software and actively maintained upstream should be okay. Please consider to reduce size as best as you can. It does not have to fit into a megabyte all together, but avoid adding things that are not useful.
optional ( create errors on start up but nothing more)
pm-utils dmidecode
Add these too.
what have to be done on existing addons
nmap: update to the latest version (to have a ncat version which supports the -U options, this is required to communicate over a normal ssh session)
Please send updates as individual patches up front.
ebtables: create some links (libvirt search in the wrong directory for the binaries)
Where?
dnsmasq enable HAVE_DHCP HAVE_SCRIPT HAVE_TFTP but I have to check this again on i686 HAVE_SCRIPT is enough, in the moment I have not the time to test where the problem is, but I will do this in the next weeks.
This will probably be a bigger issue. We are using dnsmasq just as a DNS proxy and do not use the DHCP component. If that should be used we either have to disable this in our other configuration or ship a second copy. I would like to avoid the latter.
So that is it. Now I am waiting for your opinion and what you think about this :-).
Do you have code for this already? Do you have a git repository or do you need one? We could host things if needed.
Regards Jonatan
Ps. I would maintain these packages if they become official packages.
That is a huge requirement. We just don't have the man power to do this ourselves. Although we are keen to support you when ever needed.
PSS. I use a new e-mail address because my old one is currently blocked by this server.
Which one is that? Could you maybe email me details about that in private?
Best, -Michael
Hi, thank you for your response.
Am Sa, 19. Mär, 2016 um 2:16 schrieb Michael Tremer michael.tremer@ipfire.org:
Hi,
thanks for getting in touch.
On Sat, 2016-03-19 at 09:42 +0100, Jonatan Schlag wrote:
Hi list, in October 2014 I began to build libvirt for IPFire. This failed the first time and second but now I tried it the third time with a lot more knowledge and it works well.
This is indeed something I would personally like to see in IPFire. Although I have many reasons why this is a bad idea...
So I have a running libvirt daemon on my IPFire (Arch is x86_64 works very well by the way) and want to ask if the project is interested that the libvirt package becomes an official addon.
It must be an add-on so that users do not have to install it if they don't wish to do so and to reduce attack surface.
I absolutely agree everybody should have the possibility to decide if he wants libvirt or not. Although this should be only interesting for home users. I would never recommend a libvirt addon to a company. So if libvirt is an addon like qemu or something similar it should be ok or did i miss understand you?
It could save a lot of work because everybody have the chance to install what he want in a virtual machine. Also, I think it is safer to put my owncloud into a virtual machine than to put is directly on my IPFire. Also, it could save energy because a home user has to run only one real computer.
It is probably not more secure to run a KVM machine. Breaking out of that is easy enough. However, I would also like to see some things installed on a different system instead of on IPFire itself. Just because I think that there are better distributions out there to host owncloud and similar things. It will also allow to migrate this functionality from a physical machine to IPFire or from IPFire to a physcial machine later.
That is true. There are better distributions for owncloud and so on, that was also my motivation to build libvirt for IPFire. IPFire is a very good firewall distribution, but it is not a good distribution for web hosting. But that is not a fault because IPFire is not developed for that, and this perfect. My thought was to use a virtual machine on my IPfire to server all other things I need because why should I compile 20 libraries when I have to compile 10 and then I could install everything in a virtual machine that I want.
Otherwise, libvirt is one more security risk and it is possible to break out of a virtual machine and attack the host. So these are some security aspects, but in the moment, I think there are more benefits than disadvantages. But I would like to hear your opinions on this topic.
So what are the dependencies for libvirt and what have to be done on existing packages.
Hard dependencies
util-macros libpciaccess libyajl
nice to have ( increase the usability)
opus python-six python-pyparsing spice-protocol spice
These packages provide a protocol similar to vnc (http://www.spice-space.org/)
These look okay. Basically anything that is free software and actively maintained upstream should be okay. Please consider to reduce size as best as you can. It does not have to fit into a megabyte all together, but avoid adding things that are not useful.
Thanks. I will have a look at spice and if we really need it otherwise this is the technology which is actively developed and is comparison tho vnc very fast. I try it with vnc but it is horrible to install a server when your monitor show only 5 pictures per second. So I will have a look on that, but i do not see a real change to reduce the amount of packages.
optional ( create errors on start up but nothing more)
pm-utils dmidecode
Add these too.
I will drop this.
what have to be done on existing addons
nmap: update to the latest version (to have a ncat version which supports the -U options, this is required to communicate over a normal ssh session)
Please send updates as individual patches up front.
Ok, I will send patches for everything that I listed in these part.
ebtables: create some links (libvirt search in the wrong directory for the binaries)
Where?
Libvirt looks in the /sbin directory for the binaries These are the 3 symlinks
ln -s /usr/local/sbin/ebtables-save /sbin/ebtables-save ln -s /usr/local/sbin/ebtables /sbin/ebtables ln -s /usr/local/sbin/ebtables-restore /sbin/ebtables-restore
dnsmasq enable HAVE_DHCP HAVE_SCRIPT HAVE_TFTP but I have to check this again on i686 HAVE_SCRIPT is enough, in the moment I have not the time to test where the problem is, but I will do this in the next weeks.
This will probably be a bigger issue. We are using dnsmasq just as a DNS proxy and do not use the DHCP component. If that should be used we either have to disable this in our other configuration or ship a second copy. I would like to avoid the latter.
I guessed that this would be a big problem. Libvirt start it own dnsmasq daemons so the second copy is maybe an alternative, but you are right this not a good solution. The problem is that libvirt require the DHCP option otherwise, the whole network configuration does not work. That is a big problem and make the whole thing around dnmasq more complicated. I sad to say this but in the moment, I have no real idea what we could do.
So that is it. Now I am waiting for your opinion and what you think about this :-).
Do you have code for this already? Do you have a git repository or do you need one? We could host things if needed.
I have a local git repository with all changes. But I have no online git repository. I would be very cool and helpfull if you could host one for me. :-). A big thanks for the offer that you could host the things.
Regards Jonatan
Ps. I would maintain these packages if they become official packages.
That is a huge requirement. We just don't have the man power to do this ourselves. Although we are keen to support you when ever needed.
Thanks for the help. I will maintain this packages if libvirt become an official addon
qemu and it dependencies. (When I maintain libvirt I think I make sense to maintain qemu, because libvirt is nothing without qemu. )
libvirt util-macros libpciaccess libyajl
spice spice-protocol python-pyparsing python-six opus
I know that the project has not he power to maintain all these packages, so for me it is logical to say if I want libvirt in IPFire, I have to maintain libvirt. Nevertheless, a big thanks that you want to support me if there are problems.
PSS. I use a new e-mail address because my old one is currently blocked by this server.
Which one is that? Could you maybe email me details about that in private?
Best, -Michael
I will write you a second E-Mail on this topic.
Thanks to all for the opinions on that topic.
Regards Jonatan
Hi,
On Sat, 2016-03-19 at 15:44 +0100, Jonatan Schlag wrote:
Hi, thank you for your response.
Am Sa, 19. Mär, 2016 um 2:16 schrieb Michael Tremer <michael.tremer@ipfire.org
: Hi,
thanks for getting in touch.
On Sat, 2016-03-19 at 09:42 +0100, Jonatan Schlag wrote: Hi list, in October 2014 I began to build libvirt for IPFire. This failed the first time and second but now I tried it the third time with a lot more knowledge and it works well.
This is indeed something I would personally like to see in IPFire. Although I have many reasons why this is a bad idea...
So I have a running libvirt daemon on my IPFire (Arch is x86_64 works very well by the way) and want to ask if the project is interested that the libvirt package becomes an official addon.
It must be an add-on so that users do not have to install it if they don't wish to do so and to reduce attack surface.
I absolutely agree everybody should have the possibility to decide if he wants libvirt or not. Although this should be only interesting for home users. I would never recommend a libvirt addon to a company. So if libvirt is an addon like qemu or something similar it should be ok or did i miss understand you?
No, please send patches. +1 from me.
It could save a lot of work because everybody have the chance to install what he want in a virtual machine. Also, I think it is safer to put my owncloud into a virtual machine than to put is directly on my IPFire. Also, it could save energy because a home user has to run only one real computer.
It is probably not more secure to run a KVM machine. Breaking out of that is easy enough. However, I would also like to see some things installed on a different system instead of on IPFire itself. Just because I think that there are better distributions out there to host owncloud and similar things. It will also allow to migrate this functionality from a physical machine to IPFire or from IPFire to a physcial machine later.
That is true. There are better distributions for owncloud and so on, that was also my motivation to build libvirt for IPFire. IPFire is a very good firewall distribution, but it is not a good distribution for web hosting. But that is not a fault because IPFire is not developed for that, and this perfect. My thought was to use a virtual machine on my IPfire to server all other things I need because why should I compile 20 libraries when I have to compile 10 and then I could install everything in a virtual machine that I want.
Otherwise, libvirt is one more security risk and it is possible to break out of a virtual machine and attack the host. So these are some security aspects, but in the moment, I think there are more benefits than disadvantages. But I would like to hear your opinions on this topic. So what are the dependencies for libvirt and what have to be done on existing packages. Hard dependencies util-macros libpciaccess libyajl nice to have ( increase the usability) opus python-six python-pyparsing spice-protocol spice These packages provide a protocol similar to vnc (http://www.spice-space.or g/)
These look okay. Basically anything that is free software and actively maintained upstream should be okay. Please consider to reduce size as best as you can. It does not have to fit into a megabyte all together, but avoid adding things that are not useful.
Thanks. I will have a look at spice and if we really need it otherwise this is the technology which is actively developed and is comparison tho vnc very fast. I try it with vnc but it is horrible to install a server when your monitor show only 5 pictures per second. So I will have a look on that, but i do not see a real change to reduce the amount of packages.
I think spice should be included. I assume that most people will run something like Windows in this to have a machine on a remote network to connect to and do debugging. In that case, a good remote screen protocol like spice is necessary.
optional ( create errors on start up but nothing more) pm-utils dmidecode
Add these too.
I will drop this.
I was rather saying that you should build these packages.
I would like to add dmidecode to the core system any way.
what have to be done on existing addons nmap: update to the latest version (to have a ncat version which supports the -U options, this is required to communicate over a normal ssh session)
Please send updates as individual patches up front.
Ok, I will send patches for everything that I listed in these part.
ebtables: create some links (libvirt search in the wrong directory for the binaries)
Where?
Libvirt looks in the /sbin directory for the binaries These are the 3 symlinks
ln -s /usr/local/sbin/ebtables-save /sbin/ebtables-save ln -s /usr/local/sbin/ebtables /sbin/ebtables ln -s /usr/local/sbin/ebtables-restore /sbin/ebtables-restore
We should probably move it to /usr/sbin then and libvirt should be able to find it there.
Would you be up to send a patch for that, too?
dnsmasq enable HAVE_DHCP HAVE_SCRIPT HAVE_TFTP but I have to check this again on i686 HAVE_SCRIPT is enough, in the moment I have not the time to test where the problem is, but I will do this in the next weeks.
This will probably be a bigger issue. We are using dnsmasq just as a DNS proxy and do not use the DHCP component. If that should be used we either have to disable this in our other configuration or ship a second copy. I would like to avoid the latter.
I guessed that this would be a big problem. Libvirt start it own dnsmasq daemons so the second copy is maybe an alternative, but you are right this not a good solution. The problem is that libvirt require the DHCP option otherwise, the whole network configuration does not work. That is a big problem and make the whole thing around dnmasq more complicated. I sad to say this but in the moment, I have no real idea what we could do.
We will figure this out. Start building the rest and we will have a look at this when we arrive at this point.
So that is it. Now I am waiting for your opinion and what you think about this :-).
Do you have code for this already? Do you have a git repository or do you need one? We could host things if needed.
I have a local git repository with all changes. But I have no online git repository. I would be very cool and helpfull if you could host one for me. :- ). A big thanks for the offer that you could host the things.
No worries :) I will send you another email about this.
Regards Jonatan Ps. I would maintain these packages if they become official packages.
That is a huge requirement. We just don't have the man power to do this ourselves. Although we are keen to support you when ever needed.
Thanks for the help. I will maintain this packages if libvirt become an official addon
qemu and it dependencies. (When I maintain libvirt I think I make sense to maintain qemu, because libvirt is nothing without qemu. )
libvirt util-macros libpciaccess libyajl
spice spice-protocol python-pyparsing python-six opus
I know that the project has not he power to maintain all these packages, so for me it is logical to say if I want libvirt in IPFire, I have to maintain libvirt. Nevertheless, a big thanks that you want to support me if there are problems.
We have a development Jabber channel in case you need help with the build system. Someone should usually be around.
PSS. I use a new e-mail address because my old one is currently blocked by this server.
Which one is that? Could you maybe email me details about that in private?
Best, -Michael
I will write you a second E-Mail on this topic.
Thanks to all for the opinions on that topic.
Regards Jonatan
-Michael
Hi
Am Sa, 19. Mär, 2016 um 3:57 schrieb Michael Tremer michael.tremer@ipfire.org:
Hi,
On Sat, 2016-03-19 at 15:44 +0100, Jonatan Schlag wrote:
Hi, thank you for your response.
Am Sa, 19. Mär, 2016 um 2:16 schrieb Michael Tremer <michael.tremer@ipfire.org
: Hi,
thanks for getting in touch.
On Sat, 2016-03-19 at 09:42 +0100, Jonatan Schlag wrote: Hi list, in October 2014 I began to build libvirt for IPFire. This failed
the first
time and second but now I tried it the third time with a lot
more knowledge
and it works well.
This is indeed something I would personally like to see in
IPFire. Although
I have many reasons why this is a bad idea...
So I have a running libvirt daemon on my IPFire (Arch is x86_64
works very
well by the way) and want to ask if the project is interested
that the
libvirt package becomes an official addon.
It must be an add-on so that users do not have to install it if
they don't
wish to do so and to reduce attack surface.
I absolutely agree everybody should have the possibility to decide if he wants libvirt or not. Although this should be only interesting for home users. I would never recommend a libvirt addon to a company. So if libvirt is an addon like qemu or something similar it should be ok or did i miss understand you?
No, please send patches. +1 from me.
Ok, I will send patches this evening
It could save a lot of work because everybody have the chance to
install
what he want in a virtual machine. Also, I think it is safer to put
my owncloud
into a virtual machine than to put is directly on my IPFire.
Also, it could
save energy because a home user has to run only one real
computer.
It is probably not more secure to run a KVM machine. Breaking out
of that is
easy enough. However, I would also like to see some things
installed on a
different system instead of on IPFire itself. Just because I
think that
there are better distributions out there to host owncloud and similar
things. It
will also allow to migrate this functionality from a physical machine
to IPFire
or from IPFire to a physcial machine later.
That is true. There are better distributions for owncloud and so on, that was also my motivation to build libvirt for IPFire. IPFire is a very good firewall distribution, but it is not a good distribution for web hosting. But that is not a fault because IPFire is not developed for that, and this perfect. My thought was to use a virtual machine on my IPfire to server all other things I need because why should I compile 20 libraries when I have to compile 10 and then I could install everything in a virtual machine that I want.
Otherwise, libvirt is one more security risk and it is possible
to break
out of a virtual machine and attack the host. So these are some security aspects, but in the moment, I think
there are
more benefits than disadvantages. But I would like to hear your opinions on this topic.
So what are the dependencies for libvirt and what have to be
done on
existing packages.
Hard dependencies
util-macros libpciaccess libyajl
nice to have ( increase the usability)
opus python-six python-pyparsing spice-protocol spice
These packages provide a protocol similar to vnc
g/)
These look okay. Basically anything that is free software and
actively
maintained upstream should be okay. Please consider to reduce
size as best
as you can. It does not have to fit into a megabyte all together,
but avoid
adding things that are not useful.
Thanks. I will have a look at spice and if we really need it otherwise this is the technology which is actively developed and is comparison tho vnc very fast. I try it with vnc but it is horrible to install a server when your monitor show only 5 pictures per second. So I will have a look on that, but i do not see a real change to reduce the amount of packages.
I think spice should be included. I assume that most people will run something like Windows in this to have a machine on a remote network to connect to and do debugging. In that case, a good remote screen protocol like spice is necessary.
optional ( create errors on start up but nothing more)
pm-utils dmidecode
Add these too.
I will drop this.
I was rather saying that you should build these packages.
I would like to add dmidecode to the core system any way.
Sorry, I miss understand you. I will build these things.
what have to be done on existing addons
nmap: update to the latest version (to have a ncat version which supports the -U options, this is
required to
communicate over a normal ssh session)
Please send updates as individual patches up front.
Ok, I will send patches for everything that I listed in these part.
ebtables: create some links (libvirt search in the wrong directory for the binaries)
Where?
Libvirt looks in the /sbin directory for the binaries These are the 3 symlinks
ln -s /usr/local/sbin/ebtables-save /sbin/ebtables-save ln -s /usr/local/sbin/ebtables /sbin/ebtables ln -s /usr/local/sbin/ebtables-restore /sbin/ebtables-restore
We should probably move it to /usr/sbin then and libvirt should be able to find it there.
Would you be up to send a patch for that, too?
Yes, i will send a patch for that.
dnsmasq enable HAVE_DHCP HAVE_SCRIPT HAVE_TFTP but I have to check this again on i686 HAVE_SCRIPT is enough,
in the
moment I have not the time to test where the problem is, but I will do
this in the
next weeks.
This will probably be a bigger issue. We are using dnsmasq just
as a DNS
proxy and do not use the DHCP component. If that should be used we
either have to
disable this in our other configuration or ship a second copy. I
would like
to avoid the latter.
I guessed that this would be a big problem. Libvirt start it own dnsmasq daemons so the second copy is maybe an alternative, but you are right this not a good solution. The problem is that libvirt require the DHCP option otherwise, the whole network configuration does not work. That is a big problem and make the whole thing around dnmasq more complicated. I sad to say this but in the moment, I have no real idea what we could do.
We will figure this out. Start building the rest and we will have a look at this when we arrive at this point.
Ok.
So that is it. Now I am waiting for your opinion and what you think about this
:-).
Do you have code for this already? Do you have a git repository
or do you
need one? We could host things if needed.
I have a local git repository with all changes. But I have no online git repository. I would be very cool and helpfull if you could host one for me. :- ). A big thanks for the offer that you could host the things.
No worries :) I will send you another email about this.
Thank you :)
Regards Jonatan
Ps. I would maintain these packages if they become official
packages.
That is a huge requirement. We just don't have the man power to
do this
ourselves. Although we are keen to support you when ever needed.
Thanks for the help. I will maintain this packages if libvirt become an official addon
qemu and it dependencies. (When I maintain libvirt I think I make sense to maintain qemu, because libvirt is nothing without qemu. )
libvirt util-macros libpciaccess libyajl
spice spice-protocol python-pyparsing python-six opus
I know that the project has not he power to maintain all these packages, so for me it is logical to say if I want libvirt in IPFire, I have to maintain libvirt. Nevertheless, a big thanks that you want to support me if there are problems.
We have a development Jabber channel in case you need help with the build system. Someone should usually be around.
Thank you for this informtaion. I will use it if I need help.
PSS. I use a new e-mail address because my old one is currently
blocked by
this server.
Which one is that? Could you maybe email me details about that in
private?
Best, -Michael
I will write you a second E-Mail on this topic.
Thanks to all for the opinions on that topic.
Regards Jonatan
-Michael
Regards Jonatan
Personally, I don't see the advantage of this. I run Ipfire as a KVM virtual machine under Scientific Linux. So if I wanted some specialized version of Ipfire, I would just run that instance as another VM on my existing host. On Mar 19, 2016 1:43 AM, "Jonatan Schlag" jonatan.schlag@gmail.com wrote:
Hi list, in October 2014 I began to build libvirt for IPFire. This failed the first time and second but now I tried it the third time with a lot more knowledge and it works well.
So I have a running libvirt daemon on my IPFire (Arch is x86_64 works very well by the way) and want to ask if the project is interested that the libvirt package becomes an official addon. It could save a lot of work because everybody have the chance to install what he want in a virtual machine. Also, I think it is safer to put my owncloud into a virtual machine than to put is directly on my IPFire. Also, it could save energy because a home user has to run only one real computer.
Otherwise, libvirt is one more security risk and it is possible to break out of a virtual machine and attack the host. So these are some security aspects, but in the moment, I think there are more benefits than disadvantages. But I would like to hear your opinions on this topic.
So what are the dependencies for libvirt and what have to be done on existing packages.
*Hard dependencies*
util-macros libpciaccess libyajl
*nice to have ( increase the usability)*
opus python-six python-pyparsing spice-protocol spice
These packages provide a protocol similar to vnc ( http://www.spice-space.org/)
*optional ( create errors on start up but nothing more)*
pm-utils dmidecode
*what have to be done on existing addons*
nmap: update to the latest version (to have a ncat version which supports the -U options, this is required to communicate over a normal ssh session)
ebtables: create some links (libvirt search in the wrong directory for the binaries)
dnsmasq enable HAVE_DHCP HAVE_SCRIPT HAVE_TFTP but I have to check this again on i686 HAVE_SCRIPT is enough, in the moment I have not the time to test where the problem is, but I will do this in the next weeks.
So that is it. Now I am waiting for your opinion and what you think about this :-).
Regards Jonatan
Ps. I would maintain these packages if they become official packages. PSS. I use a new e-mail address because my old one is currently blocked by this server.
-
Codermotor -
Jonatan Schlag -
Michael Tremer -
robert rottermann