With slight re-ordering to keep related things together

lars_kurth: Hi [13:52]
Are we doing this meeting on irc ?
kbsingh: yes, we are [13:59]
gwd: Hi. [14:02]
Alright. I didn’t put an agenda together
I’ve got a couple of things I wanted to bring up. [14:04]
Who else is here for the meeting?
Please do. I think KB has some too
Hello
gwd: seems we have jonludlam, kbsingh gwd and me so far [14:05]
Hi. Before we properly start. Any changes on actions on http://wiki.CentOS.org/SpecialInterestGroup/Virtualization/Status ?
So: no changes then? [14:06]
We chatted at the hackathon (with Daniel Barrange there) about libvirt versions
That was a good session [14:07]
gwd: what was the outcome/recommendation?
What we said there was that libvirt/libxl driver isn’t yet stable, so there’s no point doing a “choose a version and stick with it” thing until it is.
gwd: that is what I was afraid of [14:08]
so libvirt becomes a ‘tech preview’ until it stabilises?
Er, I don’t think “tech preview”
‘unstable’?
More like, “Not enterprise”. :-)
ok hello [14:09]
hi pasik
pasik: Hello
You know, like the kernel we want to be “enterprise” and only update every 2+ years.
But that is only an issue for libxl, mot xm. Correct? If we are still talking Xen 4.4 that should not be an issue
I don’t think we want to encourage anyone to use xend if we can possibly help it.
We need to transition people away from it. [14:10]
libvirt is a reasonable transition strategy though
Is there a need for “enterprise libvirt”? Is anyone using that? Hopefully we can get thinks into better shape with xen 4.4 +
later libvirt
Agreed. How about the needs of KVM, oVirt, … for libvirt with the current xen 4.2 packages basicly only xend is usable
(with libvirt)
pasik / euanh: We were just talking about how often to update the libvirt packages.
ovirt will take a good deal of porting to work with xen
jonludlam: correct. But this SIG is not about Xen only [14:11]
true, but
jonludlam: given how much hypervisor detail is exposed by libvirt, how reliable would a libvirt/xend -> libvirt/libxl transition go?
What was said was that ovirt effectively doesn’t need anything provided by what we’re looking at in sig virt today [14:12]
gwd, I don’t think it would be too bad – it already autodetects whether to use xl or xm based on what’s installed, if you connect to xen://
lars_kurth: I think if someone wants to use oVirt+KVM, they can use the core libvirt.
jonludlam: Sure, but as we found out, libvirt doesn’t try very hard to hide the hypervisor details. [14:13]
qemu was mentioned in the meeting at the hackathon, but it’s totally orthogonal to everything else in the SIG so far
gwd, but the difference between libxl and xend is much smaller than between qemu and xen
Sure; but it may still be a fairly major headache to get stuff to work.
kbsingh: any views? I thought you were worried about scope creep in the SIG.
Sorry: SIG [14:14]
And what actually works well with libvirt+xen at the moment anyway? xm/xl are better than virsh, IMHO
gwd: That is probably correct. On the other hand, we don’t have an interface into Cloud SIGs until we have libvirt and/or xapi
the xapi question was a bit clearer after the meetings. Anil and KB talked about an OCaml SIG that the virt SIG could
lars_kurth: Yes, but those are not going to be enterprisey either. :-)
gwd: so what is the proposal
The proprosals are: depend on
1) Choose a version of libvirt (1.2.3 maybe) and stick with it, backporting functionality we’re missing. [14:16]
2) Update the libvirt package when there’s a new libvirt release until libxl support is mature enough gwd: I use virt-install often to install new VMs gwd: imho it’s the easiest way to launch $distro installers in a PV domU [14:17]
#2 is easier for us, and will get us all the available libvirt/xen functionality; it’s what we favored at the metting at the hackathon. gwd: and virt-install works with xen4.2+xend+libvirt in el6
The only downside is that enterprise customers don’t like such frequent updates.
Daniel B said that #1 would be tricky, as they were refactoring the other bits of libvirt to make the xl plugin easier [14:18]
We really try to not break libvirt upstream, ideally having the git version run for regtests on libxl would be a good idea
DV: Upstream Xen Project already does that.
* DV agrees with danpb , even in RHEL we rebase to try to avoid backporting
Having a new libvirt shouldn’t *interfere* with oVirt, virt-install, &c&c. [14:19]
gwd: ah, good, are the result available publicly, if yes then maybe breakages should be reported on libvirt-list!
err libvir-list@
DV: Can you mail me about that separately? It’s a bit off-topic for the current meeting. :-) [14:20]
gwd: hum, the problem is that there is usually a few RHEL specific patches which used to be carried on libvirt builds
Related to the libvirt version discussion is http://lists.CentOS.org/pipermail/CentOS-virt/2014-May/003832.html gwd: and also virt-manager works OK with el6 xen4.2+xend+libvirt gwd: for basic VM management operations, and new VM installs
but I think we tried to reduce them as much as possible gwd: so maybe that answers your “And what actually works well with libvirt+xen at the moment anyway?”
pasik: ah, good to know ! [14:21]
Just to be clear: the question is NOT “do we need libvirt”. Yes, we absolutely do.
The question is, “Do we need a super-stable libvirt, or can we just update on new releases for the time being.” [14:22]
Related to that is then: how long would we be on cutting edge libvirt version (by gut feel)
gwd, and, if we are updating to new releases often, is that with a view to converging? gwd: well, CentOS6 is an enterprise stable distro, se people expect things to be (at least semi) stable. gwd: we can of course make it clear libvirt will change more often.. [14:23]
Well let’s discuss this on the list.
* DV think within the SIG the rule ‘things should be absolutely rock solid’ could be relaxed, but only a bit [14:24]
kbsingh: Actually, that’s another question: CentOS-devel isn’t really that high traffic. Would it make sense to have the development discussions held on there?
OK, so that’s going to be taken back to the list. [14:25]
OK: adding an action
gwd: are you OK to make a proposal? [14:26]
That’s all the updates I have from the status: we’re still waiting for the core CentOS team to get something set up to make contribution easier; there was some discussion of using koji, like Fedora.
lars_kurth: Yes, I’ll do that.
What next on the agenda? [14:29]
Did everyone see the Xen Hackathon meeting minutes? Anyone have any questions about that?
See http://lists.CentOS.org/pipermail/CentOS-virt/2014-June/003865.html for meeting minutes
jonludlam: “…with a view to converging” — you mean, to stop updating once libvirt+libxl is mature? Yes, that was my idea. [14:30]
yes
Cool.
although exactly how to define maturity is left unspecified
:-) [14:31]
So I had one quick question for kbsingh — should I merge my “git am” change into the main CentOS repo on github? Is there anything else that need to get that actually built?
kbsingh: AYT? [14:32]
(Or maybe hughesjr ^)
OK, I think most of what I had really needs kb’s input. :-) [14:34]
gwd: maybe ping kbsingh and/or hughesjr an e-mail (or on-list)
Related to the “build images” thing — is there a better way to make images that doesn’t require libvirt? [14:35]
Any other items from http://lists.CentOS.org/pipermail/CentOS-virt/2014-June/003865.html that we need to discuss?
The only tool like that I’ve ever used is xen-tools, which might be possible, but it would be nicer if there were something that could make images either for Xen or KVM. [14:36]
It seems it may make sense to track jonludlam about Ocaml SIG and XAPI in the actions
lars_kurth, sure
jonludlam: can you summarize that discussion briefly?
I’ll poke anil :-)
Right: anil & KB discussed creating an OCaml SIG which would take the most recent version of the ocaml compiler: 4.01 [14:37]
RHEL 7 will have 4.00.1 (not recent enough)
SIG virt could then depend upon the OCaml SIG, but crucially, only the OCaml bindings from the sig virt would then depend upon the ocaml sig [14:38]
oxenstore doesn’t need any runtime dependence on any ocaml libs
OK. Makes sense. So the ball is in Anil’s court
correct
gwd, pasik: re xen-tools … anyone knows whether there is such a thing for Xen and KVM [14:39]
lars_kurth: I don’t understand the question. [14:41]
gwd: was referring back to xen-tools … what I meant is whether virt-manager provides the same functionality + more than xen-tools
lars_kurth: virt-install I think will do that, but it depends on libvirt; which seems to confuse some people. [14:44]
gwd: re virt-install confusion. If we introduced something else, it is likely it will also confuse people. In any case may be better to rely on documentation [14:45]
virt-install> But I guess when we add an updated libvirt, then things should work more easily.
lars_kurth, btw, I had another action to send a PR with updated RPM packaging layout as an RFC
jonludlam: You should be able to d/l the tarballs manually though.
jonludlam: And I had an action to send you a how-to build the sig-virt-xen repos
yup! [14:42]
jonludlam: OK, a new one? What is the context?
jonludlam: But it turns out the binary-download thing isn’t ready yet — KB doesn’t want the world spamming his (previously) private ftp server. They’re trying to come up with a new system similar to Fedora, but it’s not ready yet. [14:43]
gwd, ok – are there many that aren’t in the current Xen4CentOS SRPM repo?
(There was just someone on CentOS-virt complaining about how hard it was to build an image for Xen4CentOS and the poor documentation.)
lars_kurth, the idea was to try to get the work done by Andy Cooper & co to reorganise the layout of the binary RPMs taken up
gwd: thank you. Got it [14:46]
jonludlum: Added the action
Looks we are running out of steam. Anything else?
No — I think following up on the “where do oVirt and xapi go”
discussion is the only other thing I had, but we need KB for that.
OK. Maybe it is better to do this on the next call. It’s easier then [14:49]
OK — any other business?
Alright: we are closed then [14:52]
OK, looks like we’re done.