We could package the libvirt files as a proper Debian package. What about moving the libvirt folder to packages/whonix-libvirt? The package (not the installation instructions on KVM wiki page) would could files to /usr/share/whonix-libvirt/xml/Whonix-Gateway_kvm.xml and so forth.
From user’s perspective nothing would change compared to now. (!)
That package wouldn’t be very useful for users. [As long as there is no Whonix Host Operating System (⚓ T21 Whonix Host Additions) and perhaps never?]
Advantages:
We could add a unit test file /usr/share/whonix-libvirt/unit_test that would import and remove the VM’s to see if the xml’s are working as expected. Eventually it would also use the xml validation tool.
That unit test could be automatically run after each and every commit using CI (Dev/Continuous Integration - Whonix). Travis CI most likely. It’s Ubuntu based, but that is still somewhat comparable to Debian. It would detect things such as missing quotes.
Then we’d have some more confirmation, that the xml files are Debian compatible.
Getting the libvirt folder out of the main source code folder.
Would make it easier to add a version number to the xml files. Since at the moment, they don’t have version numbers. We could indicate, that the version number of the xml has been increased by using debian/changelog / make deb-chl-bumpup. We could have a unit test, that runs during the build process and breaks it when the version numbers of the xml files do not match debian/changelog’s version number.
Maybe some users would notice when that package gets updated, that libvirt files are now available in a higher version number.
What do you think?
One thing. whonix-libvirt might not be the best name for the package for trademark reasons (The Tor Project Trademark versus TorBOX / Whonix). Some are rather picky about it and I like to be one the very safe side to not have to rename it later. You know any good package name that does not include “libvirt” but at the same time doesn’t limit it to kvm [because there is also qemu, in future perhaps more]?
Ok 12.04 is old in libvirt terms and so things like hypervclock are till not recognized and will trigger errors like it has done.[/quote]
We might also be able to mix with versions from higher Ubuntu repositories. Just needs to be scripted.
[quote=“HulaHoop, post:8, topic:756”]A reason for the error could be group permissions:
Using more recent versions from Ubuntu vivid now. (Ubuntu – Error) Solved some issues. virsh define and virsh undefine is now functional! Two more issues.
Log:
net-start issue.
[code]virsh -c qemu:///system net-start Whonix
error: Failed to start network Whonix
error: Unable to create bridge virbr1: Package not installed[/code]
virt-xml-validate issue.
virt-xml-validate ./usr/share/whonix-libvirt/xml/Whonix-Gateway_kvm.xml
Relax-NG validity error : Extra element devices in interleave
./usr/share/whonix-libvirt/xml/Whonix-Gateway_kvm.xml:32: element devices: Relax-NG validity error : Element domain failed to validate content
error: Unable to create bridge virbr1: Package not installed
What I found about the error is its caused by the kernel lacking bridge support for some reason. Either they don’t have bridge-utils package installed or there is some other bug in that package:
Same problem outside of CI on a Debian jessie system. (libvirt-bin 1.2.9-6)
virt-xml-validate Whonix-Gateway_qemu.xml
Relax-NG validity error : Extra element devices in interleave
Whonix-Gateway_qemu.xml:32: element devices: Relax-NG validity error : Element domain failed to validate content
Whonix-Gateway_qemu.xml fails to validate
What I found about the error is its caused by the kernel lacking bridge support for some reason. Either they don't have bridge-utils package installed or there is some other bug in that package:
The bridge-utils package is installed as per build log (https://s3.amazonaws.com/archive.travis-ci.org/jobs/44612408/log.txt). The CI's kernel could be the issue. It's running in a OpenVZ VM, that comes with some limitations.
I downloaded libvirt/kvm inside whonix from jessie repos and I can see what you describe. I started removing all the recent settings then eventually major parts of everything else, but the error keeps coming up. I think somehing is wrong with virt-xml-validate. I’ll be sure if the xml files allow a whonix guest to boot normally on a debian host. Can you please check if it does?
So I guess it should be removed for all QEMU xml files for better compatibly.
But pvspinlock is supported on the newer libvirt in Jessie. Debian stable is almost Jessie. I will remove it of course if the problem still persists on Jessie. Are you saying that its not compatible with the qemu xmls only? To be clear here when I say qemu I am talking about the pure emulator mode and not kvm.
converting xml to qemu arguments works with me.
error: unsupported configuration: setting ACPI S3 not supported
This error is directly related to power management settings:
Try and see if removing this section in the xml makes it work. I know for a fact VirtualBox does not have suspend mode available inside it for the guest acpi. It could be libvirt is seeing this unsupported on its “host” (the inside of VirtualBox) and is failing the vml because it doesn’t have this “host” capability.
The errors complain that qemu-kvm cannot be installed on the CI server.
Unrelated. Can you please not merge and instead close all the recent pull requests to libvirt XML? I don’t think the changes are worth the extra maintenance.
Two more issues.