-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
-----END PGP SIGNATURE-----
On 17.03.2014 16:57, George Dunlap wrote:
> On 03/17/2014 09:38 AM, Stefan Bader wrote:
>> On 14.03.2014 18:58, George Dunlap wrote:
>>> On 02/10/2014 03:00 PM, Stefan Bader wrote:
>>>> On 10.02.2014 15:47, George Dunlap wrote:
>>>>> On Mon, Feb 10, 2014 at 9:24 AM, Robie Basak <firstname.lastname@example.org> wrote:
>>>>>> On Fri, Jan 31, 2014 at 01:45:44PM +0000, Robie Basak wrote:
>>>>>>> Unless somebody steps up to maintain xen-api, I don't think it makes
>>>>>>> sense to continue keeping these packages in Ubuntu, given that Debian
>>>>>>> have removed them from testing and the existing packages broken (and, it
>>>>>>> seems, thus stuck in trusty-proposed). So we should remove them from
>>>>>> I have filed bug 1278352 to have these packages removed from Trusty.
>>>>> FYI, I just had a chat with the lead xapi developer. He's said that
>>>>> unfortunately management has told them not to work on the open-source
>>>>> xapi packages (at least for now); so if there is nobody in the
>>>>> community willing to maintain it, then I think removing it is probably
>>>>> the best option.
>>>>> On a related note -- what version of libvirt / Xen will be in Trusty?
>>>>> The SuSE guys have made a lot of progress on getting good support for
>>>>> libxl and libvirt; that's probably the best way forward.
>>>> Libvirt version 1.2.x (currently .1) not sure whether this may or may not
>>>> until release. Xen ... at least 4.3.2 (not yet uploaded) but there has been
>>>> interest (for the better Arm support) on 4.4. Depends a bit how soon/late the
>>>> release is compared to Trusty.
>>>> Anyway, I would like to make xl the default for new setups at least. I am
>>>> currently using it a lot together with virt-manager (though it has some odd
>>>> still) and I am being told that openstack integration is done via libvirt at
>>>> least (not sure they mandate the stack being xl or not).
>>> I've just downloaded a daily snapshot from 03/13 and gone through the process of
>>> installing Xen and testing basic functionality.
>>> A couple of suggestions:
>>> * The wiki minimally needs to be tweaked a bit for the new release; I can do
>>> that when it's closer to the release.
>>> * It would be good to be able to boot Xen be default if it's installed, without
>>> having to muck about with setting the default. Is there any chance of patching
>>> grub to reverse the default order?
>>> * It would be better to default to xl rather than xend
>>> * If you update to Xen 4.4 (which was released earlier this week) and use 1.2.2
>>> for libvirt, the libvirt/libxl driver should be really solid.
>>> If you do update to 4.4, let me know when that's done, and I can help test the
>>> libvirt integration.
>>> Another advantage of upgrading to 4.4 is that nested virtualization is much
>>> improved: you can feasibly install Xen inside a an HVM guest, and then install
>>> HVM guests inside of that. Nested virtualization is really slow, but it may be
>>> easier to test.
>> Hi George,
>> I am trying to get 4.4 into Trusty right now. In that package I changed the
>> default to xl already. The default boot is something that should be possible.
>> Maybe not immediately as I want to get the 4.4 update through feature freeze.
>> But I wanted to make some changes to grub integration anyway, so that would be
>> part of that.
> Awesome, thanks.
>> The wiki, you mean a xen.org wiki or some Ubuntu?
> I meant this page:
> The sed runes it has you type in to change the grub boot order aren't correct
> anymore, for example; and if we default to xl it should ideally be updated to
> reflect that.
Ah yeah. I just happened to meddle around with that today after another poor
soul got lost with the runes there. But I fully agree, there should be a simpler
>> Currently I got the new package only on my ppa (apt-add-repository ppa:smb/xen).
>> Adding that you could have a look at the intended package earlier. Note that
>> this always needs a recompiled libvirt due to libxen dependencies. I will try to
>> keep an up to date recompiled version in my PPA as well.
> Is it not possible for libvirt to use Xen / KVM / HyperV / whatever if they are
> present, and not use them if they are not present?
It does do that. The problem there comes from the different library versioning
approach we share with Debian. Since the version is part of the library name, a
libvirt compiled agains libvirt 4.3 will keep using the old library. This works
surprisingly well when running Xen-4.4 but as soon as you try to launch a guest
libvirtd will segfault. This is why you need a libvirt package compiled against
libxen-4.4 which the PPA tries to ensure (though I currently have to do that
manually as long as things are not in the main archive).
> If not, it doesn't seem to be very well designed...
> Anyway, I'll give it a spin sometime this week. Thanks!
Thanks for that. If you find anything let me know.