Re: [Openstack-operators] RFC: Next minimum libvirt / QEMU versions for 'T' release

2018-09-27 Thread Kashyap Chamarthy 
On Mon, Sep 24, 2018 at 09:11:42AM -0700, iain MacDonnell wrote:
> 
> 
> On 09/24/2018 06:22 AM, Kashyap Chamarthy wrote:
> > (b) Oracle Linux: Can you please confirm if you'll be able to
> >  release libvirt and QEMU to 4.0.0 and 2.11, respectively?
> 
> Hi Kashyap,
> 
> Those are already available at:
> 
> http://yum.oracle.com/repo/OracleLinux/OL7/developer/kvm/utils/x86_64/index.html

Hi Iain,

Thanks for confirming.  When you get a moment, please update the "FIXME"
for Oracle Linux:
https://wiki.openstack.org/wiki/LibvirtDistroSupportMatrix#Distro_minimum_versions

-- 
/kashyap

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] RFC: Next minimum libvirt / QEMU versions for 'T' release

2018-09-24 Thread Kashyap Chamarthy 
Hey folks,

Before we bump the agreed upon[1] minimum versions for libvirt and QEMU
for 'Stein', we need to do the tedious work of picking the NEXT_MIN_*
versions for the 'T' (which is still in the naming phase) release, which
will come out in the autumn (Sep-Nov) of 2019.

Proposal


Looking at the DistroSupportMatrix[2], it seems like we can pick the
libvirt and QEMU versions supported by the next LTS release of Ubuntu --
18.04; "Bionic", which are:

libvirt: 4.0.0
QEMU:2.11

Debian, Fedora, Ubuntu (Bionic), openSUSE currently already ship the
above versions.  And it seems reasonable to assume that the enterprise
distribtions will also ship the said versions pretty soon; but let's
double-confirm below.

Considerations and open questions
-

(a) KVM for IBM z Systems: John Garbutt pointed out[3] on IRC that:
"IBM announced that KVM for IBM z will be withdrawn, effective March
31, 2018 [...] development will not only continue unaffected, but
the options for users grow, especially with the recent addition of
SuSE to the existing support in Ubuntu."

The message seems to be: "use a regular distribution".  So this is
covered, if we a version based on other distributions.

(b) Oracle Linux: Can you please confirm if you'll be able to
release libvirt and QEMU to 4.0.0 and 2.11, respectively?

(c) SLES: Same question as above.

Assuming Oracle Linux and SLES confirm, please let us know if there are
any objections if we pick NEXT_MIN_* versions for the OpenStack 'T'
release to be libvirt: 4.0.0 and QEMU: 2.11.

* * *

A refresher on libvirt and QEMU release schedules
-

  - There will be at least 12 libvirt releases (_excluding_ maintenance
releases) by Autumn 2019.  A new libvirt release comes out every
month[4].

  - And there will be about 4 releases of QEMU.  A new QEMU release
comes out once every four months.

[1] http://git.openstack.org/cgit/openstack/nova/commit/?h=master=28d337b
-- Pick next minimum libvirt / QEMU versions for "Stein"
[2] https://wiki.openstack.org/wiki/LibvirtDistroSupportMatrix
[3] http://kvmonz.blogspot.com/2017/03/kvm-for-ibm-z-withdrawal.html
[4] https://libvirt.org/downloads.html#schedule

-- 
/kashyap

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [openstack-dev] RFC: Next minimum libvirt / QEMU versions for "Stein" release

2018-04-10 Thread Kashyap Chamarthy 
On Mon, Apr 09, 2018 at 04:24:06PM -0500, Matt Riedemann wrote:
> On 4/9/2018 4:58 AM, Kashyap Chamarthy wrote:
> > Keep in mind that Matt has a tendency to sometimes unfairly
> > over-simplify others views;-).  More seriously, c'mon Matt; I went out
> > of my way to spend time learning about Debian's packaging structure and
> > trying to get the details right by talking to folks on
> > #debian-backports.  And as you may have seen, I marked the patch[*] as
> > "RFC", and repeatedly said that I'm working on an agreeable lowest
> > common denominator.
> 
> Sorry Kashyap, I didn't mean to offend. I was hoping "delicious bugs" would
> have made that obvious but I can see how it's not. You've done a great,
> thorough job on sorting this all out.

No problem at all.  I know your communication style enough to not take
offence :-).  Thanks for the words!

> Since I didn't know what "RFC" meant until googling it today, how about
> dropping that from the patch so I can +2 it?

Sure, I meant to remove it on my last iteration; now dropped it.  (As
you noted on the review, should've used '-Workflow', but I typed "RFC"
out of muscle memory.)

Thanks for the review.

* * *

Aside: On the other patch[+] that actually bumps for "Rocky" and fixes
the resulting unit test fallout, I intend to fix the rest of the failing
tests sometime this week.  Remaining tests to be fixed:

test_live_migration_update_serial_console_xml
test_live_migration_with_valid_target_connect_addr
test_live_migration_raises_exception
test_virtuozzo_min_version_ok
test_min_version_ppc_ok
test_live_migration_update_graphics_xml
test_min_version_s390_ok

[+] https://review.openstack.org/#/c/558783/ -- libvirt: Bump
MIN_{LIBVIRT,QEMU}_VERSION for "Rocky"

-- 
/kashyap

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [openstack-dev] RFC: Next minimum libvirt / QEMU versions for "Stein" release

2018-04-09 Thread Kashyap Chamarthy 
On Fri, Apr 06, 2018 at 12:12:31PM -0500, Matt Riedemann wrote:
> On 4/6/2018 12:07 PM, Kashyap Chamarthy wrote:
> > FWIW, I'd suggest so, if it's not too much maintenance.  It'll just
> > spare you additional bug reports in that area, and the overall default
> > experience when dealing with CPU models would be relatively much better.
> > (Another way to look at it is, multiple other "conservative" long-term
> > stable distributions also provide libvirt 3.2.0 and QEMU 2.9.0, so that
> > should give you confidence.)
> > 
> > Again, I don't want to push too hard on this.  If that'll be messy from
> > a package maintainance POV for you / Debian maintainers, then we could
> > settle with whatever is in 'Stretch'.
> 
> Keep in mind that Kashyap has a tendency to want the latest and greatest of
> libvirt and qemu at all times for all of those delicious bug fixes. 

Keep in mind that Matt has a tendency to sometimes unfairly
over-simplify others views ;-).  More seriously, c'mon Matt; I went out
of my way to spend time learning about Debian's packaging structure and
trying to get the details right by talking to folks on
#debian-backports.  And as you may have seen, I marked the patch[*] as
"RFC", and repeatedly said that I'm working on an agreeable lowest
common denominator.

> But we also know that new code also brings new not-yet-fixed bugs.

Yep, of course.

> Keep in mind the big picture here, we're talking about bumping from
> minimum required (in Rocky) libvirt 1.3.1 to at least 3.0.0 (in Stein)
> and qemu 2.5.0 to at least 2.8.0, so I think that's already covering
> some good ground. Let's not get greedy. :)

Sure :-) Also if there's a way we can avoid bugs in the default
experience with minimal effort, we should.

Anyway, there we go: changed the patch[*] to what's in Stretch.

[*] https://review.openstack.org/#/c/558171/

-- 
/kashyap

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [openstack-dev] RFC: Next minimum libvirt / QEMU versions for "Stein" release

2018-04-06 Thread Kashyap Chamarthy 
On Fri, Apr 06, 2018 at 06:07:18PM +0200, Thomas Goirand wrote:
> On 04/06/2018 12:07 PM, Kashyap Chamarthy wrote:

[...]

> > Note: You don't even have to build the versions from 'Buster', which are
> > quite new.  Just the slightly more conservative libvirt 3.2.0 and QEMU
> > 2.9.0 -- only if it's possbile.
> 
> Actually, for *official* backports, it's the policy to always update to
> wwhatever is in testing until testing is frozen. 

I see.  Sure, that's fine, too (as "Queens" UCA also has it).  Whatever
is efficient and least painful from a maintenance POV.

> I could maintain an unofficial backport in stretch-stein.debian.net
> though.
>
> > That said ... I just spent comparing the release notes of libvirt 3.0.0
> > and libvirt 3.2.0[1][2].  By using libvirt 3.2.0 and QEMU 2.9.0, Debian 
> > users
> > will be spared from a lot of critical bugs (see all the list in [3]) in
> > CPU comparision area.
> > 
> > [1] 
> > https://www.redhat.com/archives/libvirt-announce/2017-April/msg0.html
> > -- Release of libvirt-3.2.0
> > [2] 
> > https://www.redhat.com/archives/libvirt-announce/2017-January/msg3.html
> > --  Release of libvirt-3.0.0
> > [3] https://www.redhat.com/archives/libvir-list/2017-February/msg01295.html
> 
> So, because of these bugs, would you already advise Nova users to use
> libvirt 3.2.0 for Queens?

FWIW, I'd suggest so, if it's not too much maintenance.  It'll just
spare you additional bug reports in that area, and the overall default
experience when dealing with CPU models would be relatively much better.
(Another way to look at it is, multiple other "conservative" long-term
stable distributions also provide libvirt 3.2.0 and QEMU 2.9.0, so that
should give you confidence.)

Again, I don't want to push too hard on this.  If that'll be messy from
a package maintainance POV for you / Debian maintainers, then we could
settle with whatever is in 'Stretch'.

Thanks for looking into it.

-- 
/kashyap

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [openstack-dev] RFC: Next minimum libvirt / QEMU versions for "Stein" release

2018-04-06 Thread Kashyap Chamarthy 
On Thu, Apr 05, 2018 at 06:11:26PM -0500, Matt Riedemann wrote:
> On 4/5/2018 3:32 PM, Thomas Goirand wrote:
> > If you don't absolutely need new features from libvirt 3.2.0 and 3.0.0
> > is fine, please choose 3.0.0 as minimum.
> > 
> > If you don't absolutely need new features from qemu 2.9.0 and 2.8.0 is
> > fine, please choose 2.8.0 as minimum.
> > 
> > If you don't absolutely need new features from libguestfs 1.36 and 1.34
> > is fine, please choose 1.34 as minimum.
> 
> New features in the libvirt driver which depend on minimum versions of
> libvirt/qemu/libguestfs (or arch for that matter) are always conditional, so
> I think it's reasonable to go with the lower bound for Debian. We can still
> support the features for the newer versions if you're running a system with
> those versions, but not penalize people with slightly older versions if not.

Yep, we can trivially set the lower bound to versions in 'Stretch'.  The
intention was never to "penalize" distributions w/ older versions.  I
was just checking if Debian 'Stretch' users can be spared from the
myriad of CPU-modelling related issues (see my other reply for
specifics) that are all fixed with 3.2.0 (and QMEU 2.9.0) by default --
without spending inordinate amounts of time and messy backporting
procedures.  Since rest of all the other stable distributions are using
it.

I'll wait a day to hear from Zigo, then I'll just rewrite the patch[*] to
use what's currently in 'Stretch'.

[*] https://review.openstack.org/#/c/558171/

-- 
/kashyap

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [openstack-dev] RFC: Next minimum libvirt / QEMU versions for "Stein" release

2018-04-06 Thread Kashyap Chamarthy 
On Thu, Apr 05, 2018 at 10:32:13PM +0200, Thomas Goirand wrote:

Hey Zigo, thanks for the detailed response; a couple of comments below.

[...]

> backport of libvirt/QEMU/libguestfs more in details
> ---
> 
> I already attempted the backports from Debian Buster to Stretch.
>
> All of the 3 components (libvirt, qemu & libguestfs) could be built
> without extra dependency, which is a very good thing.
> 
> - libvirt 4.1.0 compiled without issue, though the dh_install phase
> failed with this error:
> 
> dh_install: Cannot find (any matches for) "/usr/lib/*/wireshark/" (tried
> in "." and "debian/tmp")
> dh_install: libvirt-wireshark missing files: /usr/lib/*/wireshark/
> dh_install: missing files, aborting

That seems like a problem in the Debian packaging system, not in
libvirt.  I double-checked with the upstream folks, and the install
rules for Wireshark plugin doesn't have /*/ in there.

> - qemu 2.11 built perfectly with zero change.
> 
> - libguestfs 1.36.13 only needed to have fdisk replaced by util-linux as
> build-depends (fdisk is now a separate package in Buster).

Great.

Note: You don't even have to build the versions from 'Buster', which are
quite new.  Just the slightly more conservative libvirt 3.2.0 and QEMU
2.9.0 -- only if it's possbile.

[...]

> Conclusion:
> ---
> 
> If you don't absolutely need new features from libvirt 3.2.0 and 3.0.0
> is fine, please choose 3.0.0 as minimum.
> 
> If you don't absolutely need new features from qemu 2.9.0 and 2.8.0 is
> fine, please choose 2.8.0 as minimum.
> 
> If you don't absolutely need new features from libguestfs 1.36 and 1.34
> is fine, please choose 1.34 as minimum.
> 
> If you do need these new features, I'll do my best adapt. :)

Sure, can use the 3.0.0 (& QEMU 2.8.0), instead of 3.2.0, as we don't
want to "penalize" (that was never the intention) distros with slightly
older versions.

That said ... I just spent comparing the release notes of libvirt 3.0.0
and libvirt 3.2.0[1][2].  By using libvirt 3.2.0 and QEMU 2.9.0, Debian users
will be spared from a lot of critical bugs (see all the list in [3]) in
CPU comparision area.

[1] https://www.redhat.com/archives/libvirt-announce/2017-April/msg0.html
-- Release of libvirt-3.2.0
[2] https://www.redhat.com/archives/libvirt-announce/2017-January/msg3.html
--  Release of libvirt-3.0.0
[3] https://www.redhat.com/archives/libvir-list/2017-February/msg01295.html


[...]

-- 
/kashyap

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [openstack-dev] RFC: Next minimum libvirt / QEMU versions for "Stein" release

2018-04-04 Thread Kashyap Chamarthy 
On Sat, Mar 31, 2018 at 04:09:29PM +0200, Kashyap Chamarthy wrote:
> [Meta comment: corrected the email subject: "Solar" --> "Stein"]

Here's a change to get the discussion rolling:

https://review.openstack.org/#/c/558171/ -- [RFC] Pick next minimum
libvirt / QEMU versions for "Stein"

> On Fri, Mar 30, 2018 at 04:26:43PM +0200, Kashyap Chamarthy wrote:

[...]

> > Taking the DistroSupportMatrix into picture, for the sake of discussion,
> > how about the following NEXT_MIN versions for "Solar" release:  
> >
> > 
> > (a) libvirt: 3.2.0 (released on 23-Feb-2017)   
> > 
> > This satisfies most distributions, but will affect Debian "Stretch",
> >
> > as they only have 3.0.0 in the stable branch -- I've checked their
> > repositories[3][4].  Although the latest update for the stable
> > release "Stretch (9.4)" was released only on 10-March-2018, I don't
> > think they increment libvirt and QEMU versions in stable.  Is
> > there another way for "Stretch (9.4)" users to get the relevant
> > versions from elsewhere?

I learn that there's Debian 'stretch-backports'[0], which might provide (but
doesn't yet) a newer stable version.

> > (b) QEMU: 2.9.0 (released on 20-Apr-2017)  
> > 
> > This too satisfies most distributions but will affect Oracle Linux
> > -- which seem to ship QEMU 1.5.3 (released in August 2013) with
> > their "7", from the Wiki.  And will also affect Debian "Stretch" --
> > as it only has 2.8.0
> > 
> > Can folks chime in here?

Answering my own questions about Debian --

From looking at the Debian Archive[1][2], these are the versions for
'Stretch' (the current stable release) and in the upcoming 'Buster'
release:

libvirt | 3.0.0-4+deb9u2 | stretch
libvirt | 4.1.0-2| buster

qemu| 1:2.8+dfsg-6+deb9u3| stretch
qemu| 1:2.11+dfsg-1  | buster

I also talked on #debian-backports IRC channel on OFTC network, where I
asked: 

"What I'm essentially looking for is: "How can 'stretch' users get
libvirt 3.2.0 and QEMU 2.9.0, even if via a different repository.
As they are proposed to be least common denominator versions across
distributions."

And two people said: Then the versions from 'Buster' could be backported
to 'stretch-backports'.  The process for that is to: "ask the maintainer
of those package and Cc to the backports mailing list."

Any takers?

[0] https://packages.debian.org/stretch-backports/
[1] https://qa.debian.org/madison.php?package=libvirt
[2] https://qa.debian.org/madison.php?package=qemu

-- 
/kashyap

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] RFC: Next minimum libvirt / QEMU versions for "Stein" release

2018-03-31 Thread Kashyap Chamarthy 
[Meta comment: corrected the email subject: "Solar" --> "Stein"]

On Fri, Mar 30, 2018 at 04:26:43PM +0200, Kashyap Chamarthy wrote:
> The last version bump was in "Pike" release (commit: b980df0,
> 11-Feb-2017), and we didn't do any bump during "Queens".  So it's time
> to increment the versions (which will also makes us get rid of some
> backward compatibility cruft), and pick future versions of libvirt and
> QEMU.  
> 
> As it stands, during the "Pike" release the advertized NEXT_MIN versions  
>  
> were set to: libvirt 1.3.1 and QEMU 2.5.0 -- but they weren't actually
>  
> bumped for the "Queens" release.  So they will now be applied for the 
>  
> "Rocky" release.  (Hmm, but note that libvirt 1.3.1 was released more 
>  
> than 2 years ago[1].)  
> 
> While at it, we should also discuss about what will be the NEXT_MIN   
>  
> libvirt and QEMU versions for the "Solar" release.  To that end, I've 
>  
> spent going through different distributions and updated the   
>  
> DistroSupportMatrix Wiki[2].   
> 
> Taking the DistroSupportMatrix into picture, for the sake of discussion,
> how about the following NEXT_MIN versions for "Solar" release:
>  
> 
> (a) libvirt: 3.2.0 (released on 23-Feb-2017)   
> 
> This satisfies most distributions, but will affect Debian "Stretch",  
>  
> as they only have 3.0.0 in the stable branch -- I've checked their
> repositories[3][4].  Although the latest update for the stable
> release "Stretch (9.4)" was released only on 10-March-2018, I don't
> think they increment libvirt and QEMU versions in stable.  Is
> there another way for "Stretch (9.4)" users to get the relevant
> versions from elsewhere?   
> 
> (b) QEMU: 2.9.0 (released on 20-Apr-2017)  
> 
> This too satisfies most distributions but will affect Oracle Linux
> -- which seem to ship QEMU 1.5.3 (released in August 2013) with
> their "7", from the Wiki.  And will also affect Debian "Stretch" --
> as it only has 2.8.0
> 
> Can folks chime in here?
> 
> [1] 
> https://www.redhat.com/archives/libvirt-announce/2016-January/msg2.html
> [2] https://wiki.openstack.org/wiki/LibvirtDistroSupportMatrix
> [3] https://packages.qa.debian.org/libv/libvirt.html
> [4] https://packages.qa.debian.org/libv/libvirt.html
> 
> -- 
> /kashyap

-- 
/kashyap

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] RFC: Next minimum libvirt / QEMU versions for "Solar" release

2018-03-31 Thread Kashyap Chamarthy 
On Sat, Mar 31, 2018 at 03:17:52PM +0200, Kashyap Chamarthy wrote:
> On Fri, Mar 30, 2018 at 09:49:17AM -0500, Sean McGinnis wrote:

[...]

> > > Taking the DistroSupportMatrix into picture, for the sake of discussion,
> > > how about the following NEXT_MIN versions for "Solar" release:
> > >  
> > > 
> > Correction - for the "Stein" release. :)
> 
> Darn, I should've triple-checked before I assumed it is to be "Solar".
> If "Stein" is confirmed; I'll re-send this email with the correct
> release name for clarity.

It actually is:

http://lists.openstack.org/pipermail/openstack-dev/2018-March/128899.html
-- All Hail our Newest Release Name - OpenStack Stein

(That email went into 'openstack-operators' maildir for me; my filtering
fault.)

I won't start another thread;, will just leave this existing thread
intact, as people will read it as: "whatever name the 'S' release ends
up with" (as 'fungi' put it on IRC).

[...]

-- 
/kashyap

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] RFC: Next minimum libvirt / QEMU versions for "Solar" release

2018-03-31 Thread Kashyap Chamarthy 
On Fri, Mar 30, 2018 at 09:49:17AM -0500, Sean McGinnis wrote:
> > While at it, we should also discuss about what will be the NEXT_MIN 
> >
> > libvirt and QEMU versions for the "Solar" release.  To that end, I've   
> >
> > spent going through different distributions and updated the 
> >
> > DistroSupportMatrix Wiki[2].   
> > 
> > Taking the DistroSupportMatrix into picture, for the sake of discussion,
> > how about the following NEXT_MIN versions for "Solar" release:  
> >
> > 
> Correction - for the "Stein" release. :)

Darn, I should've triple-checked before I assumed it is to be "Solar".
If "Stein" is confirmed; I'll re-send this email with the correct
release name for clarity.

Thanks for correcting.

-- 
/kashyap

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] RFC: Next minimum libvirt / QEMU versions for "Solar" release

2018-03-30 Thread Kashyap Chamarthy 
The last version bump was in "Pike" release (commit: b980df0,
11-Feb-2017), and we didn't do any bump during "Queens".  So it's time
to increment the versions (which will also makes us get rid of some
backward compatibility cruft), and pick future versions of libvirt and
QEMU.  

As it stands, during the "Pike" release the advertized NEXT_MIN versions
   
were set to: libvirt 1.3.1 and QEMU 2.5.0 -- but they weren't actually  
   
bumped for the "Queens" release.  So they will now be applied for the   
   
"Rocky" release.  (Hmm, but note that libvirt 1.3.1 was released more   
   
than 2 years ago[1].)  

While at it, we should also discuss about what will be the NEXT_MIN 
   
libvirt and QEMU versions for the "Solar" release.  To that end, I've   
   
spent going through different distributions and updated the 
   
DistroSupportMatrix Wiki[2].   

Taking the DistroSupportMatrix into picture, for the sake of discussion,
how about the following NEXT_MIN versions for "Solar" release:  
   

(a) libvirt: 3.2.0 (released on 23-Feb-2017)   

This satisfies most distributions, but will affect Debian "Stretch",
   
as they only have 3.0.0 in the stable branch -- I've checked their
repositories[3][4].  Although the latest update for the stable
release "Stretch (9.4)" was released only on 10-March-2018, I don't
think they increment libvirt and QEMU versions in stable.  Is
there another way for "Stretch (9.4)" users to get the relevant
versions from elsewhere?   

(b) QEMU: 2.9.0 (released on 20-Apr-2017)  

This too satisfies most distributions but will affect Oracle Linux
-- which seem to ship QEMU 1.5.3 (released in August 2013) with
their "7", from the Wiki.  And will also affect Debian "Stretch" --
as it only has 2.8.0

Can folks chime in here?

[1] https://www.redhat.com/archives/libvirt-announce/2016-January/msg2.html
[2] https://wiki.openstack.org/wiki/LibvirtDistroSupportMatrix
[3] https://packages.qa.debian.org/libv/libvirt.html
[4] https://packages.qa.debian.org/libv/libvirt.html

-- 
/kashyap

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] Call For Proposals: KVM Forum 2017 [Submission deadline: 15-JUN-2017]

2017-06-09 Thread Kashyap Chamarthy 

KVM Forum 2017: Call For Participation
October 25-27, 2017 - Hilton Prague - Prague, Czech Republic

(All submissions must be received before midnight June 15, 2017)
=


KVM Forum is an annual event that presents a rare opportunity
for developers and users to meet, discuss the state of Linux   
virtualization technology, and plan for the challenges ahead.
We invite you to lead part of the discussion by submitting a speaking
proposal for KVM Forum 2017.

At this highly technical conference, developers driving innovation
in the KVM virtualization stack (Linux, KVM, QEMU, libvirt) can
meet users who depend on KVM as part of their offerings, or to
power their data centers and clouds.

KVM Forum will include sessions on the state of the KVM
virtualization stack, planning for the future, and many
opportunities for attendees to collaborate. As we celebrate ten years
of KVM development in the Linux kernel, KVM continues to be a
critical part of the FOSS cloud infrastructure.

This year, KVM Forum is joining Open Source Summit in Prague,
Czech Republic. Selected talks from KVM Forum will be presented on
Wednesday October 25 to the full audience of the Open Source Summit.
Also, attendees of KVM Forum will have access to all of the talks from
Open Source Summit on Wednesday.


===
IMPORTANT DATES
===
Submission deadline: June 15, 2017
Notification: August 10, 2017
Schedule announced: August 17, 2017
Event dates: October 25-27, 2017

http://events.linuxfoundation.org/cfp

Suggested topics:
* Scaling, latency optimizations, performance tuning, real-time guests
* Hardening and security
* New features
* Testing

KVM and the Linux kernel:
* Nested virtualization
* Resource management (CPU, I/O, memory) and scheduling
* VFIO: IOMMU, SR-IOV, virtual GPU, etc.
* Networking: Open vSwitch, XDP, etc.
* virtio and vhost
* Architecture ports and new processor features

QEMU:
* Management interfaces: QOM and QMP
* New devices, new boards, new architectures
* Graphics, desktop virtualization and virtual GPU
* New storage features
* High availability, live migration and fault tolerance
* Emulation and TCG
* Firmware: ACPI, UEFI, coreboot, U-Boot, etc.

Management and infrastructure
* Managing KVM: Libvirt, OpenStack, oVirt, etc.
* Storage: Ceph, Gluster, SPDK, etc.
* Network Function Virtualization: DPDK, OPNFV, OVN, etc.
* Provisioning


===
SUBMITTING YOUR PROPOSAL
===
Abstracts due: June 15, 2017

Please submit a short abstract (~150 words) describing your presentation
proposal. Slots vary in length up to 45 minutes. Also include the proposal
type -- one of:
- technical talk
- end-user talk

Submit your proposal here:
http://events.linuxfoundation.org/cfp
Please only use the categories "presentation" and "panel discussion"

You will receive a notification whether or not your presentation proposal
was accepted by August 10, 2017.

Speakers will receive a complimentary pass for the event. In the instance
that case your submission has multiple presenters, only the primary speaker for 
a
proposal will receive a complimentary event pass. For panel discussions, all
panelists will receive a complimentary event pass.

TECHNICAL TALKS

A good technical talk should not just report on what has happened over
the last year; it should present a concrete problem and how it impacts
the user and/or developer community. Whenever applicable, focus on
work that needs to be done, difficulties that haven't yet been solved,
and on decisions that other developers should be aware of. Summarizing
recent developments is okay but it should not be more than a small
portion of the overall talk.

END-USER TALKS

One of the big challenges as developers is to know what, where and how
people actually use our software. We will reserve a few slots for end
users talking about their deployment challenges and achievements.

If you are using KVM in production you are encouraged submit a speaking
proposal. Simply mark it as an end-user talk. As an end user, this is a
unique opportunity to get your input to developers.

HANDS-ON / BOF SESSIONS

We will reserve some time for people to get together and discuss
strategic decisions as well as other topics that are best solved within
smaller groups.

These sessions will be announced during the event. If you are interested
in organizing such a session, please add it to the list at

  http://www.linux-kvm.org/page/KVM_Forum_2017_BOF

Let people you think who might be interested know about your BOF, and encourage
them to add their names to the wiki page as well. Please try to
add your ideas to the list before KVM Forum starts.


PANEL DISCUSSIONS

If you are proposing a panel discussion, please make sure that you list
all of your potential panelists in your the abstract. We will request full
biographies if a panel is accepted.


===
HOTEL /

Re: [Openstack-operators] User Survey usage of QEMU (as opposed to KVM) ?

2016-05-11 Thread Kashyap Chamarthy 
On Tue, May 03, 2016 at 02:27:00PM -0500, Sergio Cuellar Valdes wrote:

[...]

> I'm confused too about the use of KVM or QEMU In the computes the
> file​/etc/nova/nova-compute.conf has:
> 
> virt_type=kvm
> 
> The output of:
> 
> nova hypervisor-show  | grep hypervisor_type
> 
> is:
> 
> hypervisor_type   | QEMU

As Dan noted in his response, it's because it is reporting the libvirt driver
name (which is reported as QEMU).

Refer below if you want to double-confirm if your instances are using KVM.

> 
> The virsh dumpxml of the instances shows:
> 
> 

That means, yes, you using KVM.  You can confirm that by checking your QEMU
command-line of the Nova instance, you'll see something like "accel=kvm":

# This is on Fedora 23 system
$ ps -ef | grep -i qemu-system-x86_64
[...] /usr/bin/qemu-system-x86_64 -machine accel=kvm [...]

> 
> /usr/bin/qemu-system-x86_64
> 
> ​But according to ​this document [1], it is using QEMU emulator instead of
> KVM, because it is not using /usr/bin/qemu-kvm
>
> 
> So I really don't know if it's using KVM or QEMU.

As noted above, a sure-fire way to know is to see if the instance's QEMU
command-line has "accel=kvm".

A related useful tool is `virt-host-validate` (which is part of libvirt-client
package, at least on Fedora-based systems):

   $ virt-host-validate | egrep -i 'kvm'
QEMU: Checking if device /dev/kvm exists   
: PASS
QEMU: Checking if device /dev/kvm is accessible
: PASS


> [1] https://libvirt.org/drvqemu.html
> 


-- 
/kashyap

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] raw ephemeral disks and qcow2 images

2015-10-23 Thread Kashyap Chamarthy 
On Fri, Oct 23, 2015 at 10:45:29AM +, Tim Bell wrote:
> https://bugs.launchpad.net/nova/+bug/1509304 has been reported.

Thanks, I slightly reworded the description to this:

"Add support for 'l2-cache-size' (a QCOW2 run time option for
metadata cache size) for drives"

And, added some URLs with documentation.

> Not sure the best place to ask for the option... something in
> nova.conf may allocate too much memory if not many VMs need it but
> adding support in flavors/images would be more complex. This could be
> done in stages.

Yeah, this needs input from other Nova developers who're more familiar
with the intricacies of qcow2 cache configuration.


> > -Original Message-----
> > From: Kashyap Chamarthy [mailto:kcham...@redhat.com]
> > Sent: 23 October 2015 12:37
> > To: Tim Bell <tim.b...@cern.ch>
> > Cc: Marc Heckmann <marc.heckm...@ubisoft.com>; openstack-
> > operat...@lists.openstack.org
> > Subject: Re: [Openstack-operators] raw ephemeral disks and qcow2 images
> > 
> > On Fri, Oct 23, 2015 at 06:21:23AM +, Tim Bell wrote:
> > >
> > > On 22/10/15 20:01, "Marc Heckmann" <marc.heckm...@ubisoft.com>
> > wrote:
> > >
> > > >Hi,
> > > >
> > > >On Thu, 2015-10-22 at 08:17 -0700, Abel Lopez wrote:
> > > >> I've actually looked for this for our RBD backed ephemeral
> > > >> instances, but found the options lacking. I last looked in Juno.
> > > >>
> > > >> On Thursday, October 22, 2015, Tim Bell <tim.b...@cern.ch> wrote:
> > > >>
> > > >>
> > > >> Has anyone had experience with setting up Nova with KVM so it
> > > >> has raw ephemeral disks but qcow2 images for the VMs ? We’ve
> > > >> got very large ephemeral disks and could benefit from the
> > > >> performance of raw volumes for this.
> > > >
> > > >We looked into this for the very same reasons and it doesn't seem to
> > > >be supported.
> > > >
> > > >That being said, I'm fearful of the boot time performance impact of
> > > >using RAW for ephemeral.
> > > >
> > > >I suggest you check out the following presentation about qcow2
> > > >performance if you haven't already done so:
> > > >
> > > >http://events.linuxfoundation.org/sites/events/files/slides/p0.pp_.pd
> > > >f
> > 
> > I was about to recommend this (/me was present in this session in person).
> > 
> > Also, slightly off-topic: I'd recommend the "Incremental Backups"
> > session:
> > 
> > 
> > http://events.linuxfoundation.org/sites/events/files/slides/kvm2015_rh_lig
> > ht_44_vfinal.pdf
> > 
> > > >I think it would be worthwhile for Openstack (and libvirt if
> > > >required) to support the "l2-cache-size" option for qcow2.
> > >
> > > +1 for l2-cache-size. This presentation was the basis under which I
> > > was looking for a temporary approach until we get the latest qcow2
> > > support.
> > 
> > Would you or Marc like to file a bug report to track this?
> > 
> > The 'l2-cache-size' runtime pption to '-drive' command-line argument is a
> > recent addition (AUG-2015):
> > 
> > [...]-drive file=hd.qcow2,l2-cache-size=2097152[...]
> > 

-- 
/kashyap

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] raw ephemeral disks and qcow2 images

2015-10-23 Thread Kashyap Chamarthy 
On Fri, Oct 23, 2015 at 06:21:23AM +, Tim Bell wrote:
> 
> On 22/10/15 20:01, "Marc Heckmann"  wrote:
> 
> >Hi,
> >
> >On Thu, 2015-10-22 at 08:17 -0700, Abel Lopez wrote:
> >> I've actually looked for this for our RBD backed ephemeral instances,
> >> but found the options lacking. I last looked in Juno. 
> >> 
> >> On Thursday, October 22, 2015, Tim Bell  wrote:
> >>  
> >> 
> >> Has anyone had experience with setting up Nova with KVM so it
> >> has raw ephemeral disks but qcow2 images for the VMs ? We’ve
> >> got very large ephemeral disks and could benefit from the
> >> performance of raw volumes for this.
> >
> >We looked into this for the very same reasons and it doesn't seem to be
> >supported.
> >
> >That being said, I'm fearful of the boot time performance impact of
> >using RAW for ephemeral. 
> >
> >I suggest you check out the following presentation about qcow2
> >performance if you haven't already done so:
> >
> >http://events.linuxfoundation.org/sites/events/files/slides/p0.pp_.pdf

I was about to recommend this (/me was present in this session in
person).

Also, slightly off-topic: I'd recommend the "Incremental Backups"
session:


http://events.linuxfoundation.org/sites/events/files/slides/kvm2015_rh_light_44_vfinal.pdf

> >I think it would be worthwhile for Openstack (and libvirt if required)
> >to support the "l2-cache-size" option for qcow2.
>
> +1 for l2-cache-size. This presentation was the basis under which I
> was looking for a temporary approach until we get the latest qcow2
> support.

Would you or Marc like to file a bug report to track this?

The 'l2-cache-size' runtime pption to '-drive' command-line argument is
a recent addition (AUG-2015):

[...]-drive file=hd.qcow2,l2-cache-size=2097152[...]

-- 
/kashyap

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [nova] Change from Mitaka: Expected UNIX signal to generate Guru Meditation (error) Reports

2015-10-21 Thread Kashyap Chamarthy 
Background
--

Oslo Guru Meditation (error) Reports (GMR)[*] are a useful debugging
mechanism that allows one to capture the current state of a Nova
process/executable (e.g. `nova-compute`, `nova-api`, etc).

The way to generate the error report is to supply the 'User-defined
signal', SIGUSR1, when killing a Nova process.  E.g.

$ kill -USR1 `pgrep nova-compute`

which results in GMR being printed to your standard error ('stderr')
stream, wherever it ends up being redirected to (e.g. to a corresponding
Nova process-specific log file, otherwise, on systemd-enabled systems,
to its journal).


Change in Mitaka (and above)


>From the upcoming Mitaka release onwards, the default expected UNIX
signal to generate GMR has been changed[1] from USR1 to USR2 (another
User-defined singal), because the USR1 is reserved by Apache 'mod_wsgi'
for its own purpose.

So, to generate GMR, from Mitaka release:

$ kill -USR2 `pgrep nova-compute`

A corresponding Nova documentation change[2] has been submitted to
reflect this new reality.


[1] https://review.openstack.org/#/c/223133/ -- guru_meditation_report:
Use SIGUSR2 instead of SIGUSR1 
[2] https://review.openstack.org/#/c/227779/ -- doc: gmr: Update
instructions to generate GMR error reports


[*] References
--

Related reading:

- http://docs.openstack.org/developer/nova/gmr.html
- http://docs.openstack.org/developer/oslo.reports/usage.html
- https://wiki.openstack.org/wiki/GuruMeditationReport
- 
https://www.berrange.com/posts/2015/02/19/nova-and-its-use-of-olso-incubator-guru-meditation-reports/

-- 
/kashyap

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators