Re: [CentOS-virt] Xen Version update policy

[George Dunlap]

On Fri, Dec 13, 2019 at 12:32 AM Steven Haigh  wrote:
>
> On 2019-12-13 04:54, Kevin Stange wrote:
> > I don't want to burden Steven Haigh any, but I wonder if there's a way
> > we could combine some of our efforts to make both "Xen made easy!" and
> > the Virt SIG Xen easier to manage.
>
> I've been thinking about this for a while. The problem has been the
> workflows between myself and the SIG are so far apart, its hard to look
> at how to merge them.
>
> I have full CI between my own git and packages to the mirrors - which is
> good, but has its down sides. I also don't have the restrictions of the
> CentOS build system to deal with - which is great for my workflow ;)

AIUI Anthony's personal build script kicks off a CBS build, runs the
result in osstest (the upstream XenProject's CI system), then pushes
them to testing.

XenProject's CI system is more focused on interoperability with all
the other projects we interact with than on depth of coverage; but
that's just about right for the CentOS packages -- only the packaging
itself should really need to be tested.  Everything else should
already have been tested by upstream partners before the release.

IIRC from the last discussion we had, probably one of the more
annoyingly sticky issues is dealing with different configurations; in
particular different dom0 kernel configurations.  Any major changes
risks having one of our downstreams suddenly stop working.

 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

Re: [CentOS-virt] Xen Version update policy

[George Dunlap]

On Fri, Dec 13, 2019 at 1:06 PM Nils Meyer  wrote:
> On 13/12/2019 01.31, Steven Haigh wrote:
> > 2) There's no brctl in CentOS 8. The network scripts need to be
> > re-written to use 'ip' instead. To maintain compatibility, the network
> > scripts need to support both brctl and ip commands and use whichever is
> > present on the system.
>
> I think the default is to use Network Manager / nmcli? I'm not sure if
> NM is going to do things with interfaces you created through ip.

For VMs, these interfaces are created by Xen's toolstack when the VM
is started and destroyed by Xen's toolstack when the VM is destroyed;
generally speaking all that's needed is for them to be plumbed into
the bridge with the right mac address.  The guest then does all of its
own DHCP   As long as that can be done via `ip`, there's nothing NM
really needs to do.

 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

Re: [CentOS-virt] Xen Version update policy

[George Dunlap]

On Thu, Nov 28, 2019 at 6:12 PM George Dunlap  wrote:
>
> Hey all,
>
> This mail has been a long time in coming, but with the upcoming
> expiration of security support for Xen 4.8, it's time to start thinking
> about what our update policy will be for the Xen packages in general.
>
> Citrix is committed to officially supporting one Xen version at a time
> through the CentOS Virt SIG.  (Others in the community are welcome to
> support others.)  But we'd like input as to which version the community
> would like to be supported at any one time.
>
> Please express your opinion on each option by replying as follows:
> -2: This is a bad idea, and I would argue against this
> -1: I'm not happy with this, but I wouldn't argue against this.
> 0: No opinion.
> 1: I'm happy with this, but I wouldn't argue for it.
> 2: This is a great idea, and I'd argue for it.
>
> There are several possible options:
>
> 1. Always support the newest option.  This means we get all the newest
> features from Xen in the Virt SIG by default; but also means we get all
> the newest bugs.
>
> 1a. Always support the newest option once it has at least one point
> release.  This balances the newness with a bit of extra testing.
>
> 1b. Always support the second-to-newest version (e.g., when 4.13 comes
> out, switch to 4.12.x)
>
> 2. Always support the oldest security-supported version.  This means we
> get the most stable version of Xen; but it does mean it is several years
> behind as far as features go.  It also means that further bugfixes do
> not happen automatically, and further bugs found will need to be
>
> 3. Always support the oldest fully-supported version.  Reasonably
> stable, reasonably old, still gets bugfixes.
>
> 4. Support a version until it's out of security support, then jump to
> the newest version.  This minimizes the number of upgrades required
> (although may make each upgrade more painful).
>
> 4a.  Support a version until it's out of full support, then jump to the
> newest version.

So the voting results look sort of like this:

1: 0, -2
1a: 1, -1
1b: 1, 2
 -> 1 or 1a or 1b: +2

2:  0, -2
3:  0, 2
4:  0, -1, -1
4a: 0, -2, -1

Meaning 1b, "Always support the second-to-newest version" seems to be
the best fit.

Since a 4.13 release is imminent, I think we'll probably switch to
4.12 as the default / main supported release once that's out, and then
update every release.

 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

Re: [CentOS-virt] Xen Version update policy

[George Dunlap]

On Mon, Dec 2, 2019 at 5:08 PM Kevin Stange  wrote:
> By supporting only even numbered releases as is the case now, it has not
> been possible to do hot migration based upgrades which means that we
> have to do full reboots of our entire environment every so often.  Right
> now we're running on Xen 4.8 and transitioning to 4.12 directly.  We
> skipped 4.10 because we felt that 4.12 has been out and stable for long
> enough.  Ideally if every major build of Xen were provided we would
> transition by hot migrations up to the next release periodically and
> stay on a security supported release each time one is going toward EOL.
>
> Personally I would love to see at the very least transitional packages
> for each Xen version available to allow for easier hot migrations to the
> latest release, under the assumption that such migrations are considered
> "supported" upstream.  I believe you said this was to be expected in a
> previous conversation we had on IRC.

The original purpose of only doing every other release was to make
sure that maintenance of the packages wouldn't take too much of our
time; but I think at the current state of things, updating ever
release should be fine.  (Particularly now that we've spread out
releases again.)

> I don't really think we should drop a release before its security
> support ends, unless we have *really clear* communication to repo users
> as to the life cycles of these builds in advance.

Indeed, the purpose of this email is in fact to make such a clear
communication.  Citrix (i.e., Anthony & I) have committed to providing
up-to-date packages for one version at a time; this is meant to give
people input into which version that is.  The Virt SIG cannot as a
whole commit to supporting releases until security support ends unless
others step up and make commitments to do so.

> I get why providing updates for 5 major releases concurrently is
> prohibitive for the entire security support period, though if it were
> more automated, maybe it would be easier to manage.

Indeed; I think the main barrier to having the whole thing automated
from xen.git/staging-VV to mirror.centos.org is testing.  If we had at
least a reasonable subset of automated testing between buildlogs and
mirror, I'd feel comfortable with an automated push.  Alternately, if
people were comfortable with "the community has 1 week to test and
object before an automated push happens", we could do that too.

 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

Re: [CentOS-virt] Xen Version update policy

[George Dunlap]

On Thu, Nov 28, 2019 at 6:12 PM George Dunlap  wrote:
 newest version.
>
> Any other options?

Thanks to everyone who has responded so far.  I plan to collect
responses on 12 December (2 weeks from when I sent the initial email)
and try to make a decision.

 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

[CentOS-virt] Xen Version update policy

[George Dunlap]

Hey all,

This mail has been a long time in coming, but with the upcoming
expiration of security support for Xen 4.8, it's time to start thinking
about what our update policy will be for the Xen packages in general.

Citrix is committed to officially supporting one Xen version at a time
through the CentOS Virt SIG.  (Others in the community are welcome to
support others.)  But we'd like input as to which version the community
would like to be supported at any one time.

Please express your opinion on each option by replying as follows:
-2: This is a bad idea, and I would argue against this
-1: I'm not happy with this, but I wouldn't argue against this.
0: No opinion.
1: I'm happy with this, but I wouldn't argue for it.
2: This is a great idea, and I'd argue for it.

There are several possible options:

1. Always support the newest option.  This means we get all the newest
features from Xen in the Virt SIG by default; but also means we get all
the newest bugs.

1a. Always support the newest option once it has at least one point
release.  This balances the newness with a bit of extra testing.

1b. Always support the second-to-newest version (e.g., when 4.13 comes
out, switch to 4.12.x)

2. Always support the oldest security-supported version.  This means we
get the most stable version of Xen; but it does mean it is several years
behind as far as features go.  It also means that further bugfixes do
not happen automatically, and further bugs found will need to be

3. Always support the oldest fully-supported version.  Reasonably
stable, reasonably old, still gets bugfixes.

4. Support a version until it's out of security support, then jump to
the newest version.  This minimizes the number of upgrades required
(although may make each upgrade more painful).

4a.  Support a version until it's out of full support, then jump to the
newest version.

Any other options?

For my part, I think 1a, 1b, and 3 are all reasonable options.

-George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

[CentOS-virt] Xen-kernel: Update to 4.14 or 4.19?

[George Dunlap]

Hey all,

We've been on 4.9 for some time now, and while it's still supported, I
think it's time to start thinking about upgrading, and I'd like input
from the community about which version to move up to.

4.19 has been out for almost 5 months now.  It will include PVH domU
support, and PVH dom0 support in what _is believed_ to be the final
form; so when the Virt SIG moves to a version of Xen that supports PVH
dom0, the kernel will already be in place with no need to upgrade.

The other option would be to move to 4.14: Probably more stable (as
it's been out for over a year now), but doesn't have either PVH domU
or PVH dom0 support.

I'd suggest 4.19. Any other opinions?

 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

Re: [CentOS-virt] CentOS 7.6 and Xen 4.6 / centos-release-xen broken

[George Dunlap]

On Sat, Feb 9, 2019 at 4:50 PM Pasi Kärkkäinen  wrote:
>
> Hi,
>
> On Sat, Feb 09, 2019 at 06:39:59PM +0200, Pasi Kärkkäinen wrote:
> > Hello George,
> >
> > On Thu, Nov 01, 2018 at 12:06:49PM +, George Dunlap wrote:
> > > Hey all,
> > >
> > > In order to make sure SIG content is "fresh", whenever a new version
> > > of CentOS comes out, content is discarded automatically unless SIG
> > > chairs specifically request it to be moved over.
> > >
> > > At the moment, Xen has three repos that are under consideration to be 
> > > moved up:
> > >
> > > virt/x86_64/xen-46
> > > virt/x86_64/xen-48
> > > virt/x86_64/xen-410
> > >
> > > I'll request xen-48 and xen-410 to be updated for sure, but I wanted
> > > to gauge how much interest there was in xen-46.  If you have strong
> > > feelings about xen-46, let me know (and perhaps consider volunteering
> > > to maintain the packages).
> > >
> >
> > It seems currently "centos-release-xen" package is broken in CentOS7,
> > it points to xen-46 repo, which isn't available anymore in CentOS 7.6:
> >
> > http://mirror.centos.org/centos/7/virt/x86_64/
> >
> >   -> xen-48/
> >   -> xen-410/
> >
> >
> > # yum clean all
> > # yum search centos-release-xen
> > ..
> > centos-release-xen.x86_64 : CentOS Virt SIG Xen repo configs
> > centos-release-xen-48.x86_64 : CentOS Virt Sig Xen repo configs for Xen 4.8
> > centos-release-xen-common.x86_64 : CentOS Virt Sig Xen support files
> > ..
> >
> > # yum install centos-release-xen
> > # cat /etc/yum.repos.d/CentOS-Xen.repo
> >
> > # CentOS-Xen.repo
> > #
> > # Please see http://wiki.centos.org/QaWiki/Xen4 for more
> > # information
> >
> > [centos-virt-xen-46]
> > name=CentOS-$releasever - xen
> > baseurl=http://mirror.centos.org/centos/$releasever/virt/$basearch/xen-46
> > gpgcheck=1
> > enabled=1
> > gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-SIG-Virtualization
> >
> > [centos-virt-xen-46-testing]
> > name=CentOS-$releasever - xen - testing
> > baseurl=http://buildlogs.centos.org/centos/$releasever/virt/$basearch/xen-46
> > gpgcheck=0
> > enabled=0
> > gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-SIG-Virtualization
> >
> >
> > I guess two things should happen in CentOS7:
> >
> > 1) Publish centos-release-xen-410 package
> >
>
> Ah, actually it's there already in xen-48 and xen-410 dirs, but not in CentOS 
> extras.
>
>
> > 2) Update centos-release-xen package to point to.. 410 ?
> >
>
> So it seems the "centos-release-xen" package in "extras" repo has the xen-46 
> reference in it.
> So we should update the package in extras.

Sorry, missed this -- yes, we've been trying to get the powers that be
to update it for some time; we did finally manage to get it updated a
week or two ago.  Could you give it a try now?

 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

[CentOS-virt] CentOS 7.6 and Xen 4.6

[George Dunlap]

Hey all,

In order to make sure SIG content is "fresh", whenever a new version
of CentOS comes out, content is discarded automatically unless SIG
chairs specifically request it to be moved over.

At the moment, Xen has three repos that are under consideration to be moved up:

virt/x86_64/xen-46
virt/x86_64/xen-48
virt/x86_64/xen-410

I'll request xen-48 and xen-410 to be updated for sure, but I wanted
to gauge how much interest there was in xen-46.  If you have strong
feelings about xen-46, let me know (and perhaps consider volunteering
to maintain the packages).

Thanks,
 -George

-- Forwarded message -
From: Anssi Johansson 
Date: Thu, Nov 1, 2018 at 9:02 AM
Subject: [CentOS-devel] SIGs: Possibility to drop EOL content at
7.6.1810 release time
To: The CentOS developers mailing list. 


So here we go again. As one of the virtues of a programmer is laziness,
I'll just cut the previous email with some modifications. You know
the drill.

RHEL 7.6 was released a few days ago and building CentOS 7.6.1810 has
just started. This would be an excellent time to remove any EOL software
you may have floating around on mirror.centos.org. mirror.centos.org
should have only supported packages available.

SIGs should explicitly state which content they want copied over from
7.5.1804 to 7.6.1810.

I'd imagine that for example ceph-jewel could be dropped because it went
EOL in July 2018. Is there some other content that could be dropped? If
you are planning to keep content available that has gone EOL upstream,
you must commit to backport any required security fixes to it.

If SIGs want to transfer some of their packages from 7.5.18004 to
7.6.1810, please let hughesjr know. You can probably simply reply to
this message to let people know of your decision. It is possible that
some other SIG depends on your packages that are going to be removed. In
that case the other SIG should probably update their packages to depend
on supported versions.

Content to be transferred over to 7.6.1810 can be specified either by
directory name, or by individual package names.

There are also various centos-release-* packages in extras,
http://mirror.centos.org/centos/7.5.1804/extras/x86_64/Packages/ ,
perhaps some of those could be trimmed as well.

You should also communicate to your users in advance that the EOL
packages will disappear, and if necessary, instruct them to migrate to a
newer supported version. Having instructions for that procedure
published somewhere would be nice.

The old content under 7.5.1804, including any EOL content, will be
archived to vault.centos.org, and that content will be available in the
vault indefinitely. The 7.5.1804 directory on mirror.centos.org will be
emptied some time after 7.6.1810 is released.

For reference and inspiration, here are some directories from
mirror.centos.org, including both up-to-date content and potentially EOL
content. SIGs should review the list to make sure these directories can
be copied over to 7.6.1810 when that time comes. Making the decisions
now would save a bit of time at 7.6.1810 release time.

cloud/x86_64/openstack-ocata
cloud/x86_64/openstack-pike
cloud/x86_64/openstack-queens
cloud/x86_64/openstack-rocky
configmanagement/x86_64/ansible26
configmanagement/x86_64/yum4
dotnet
nfv/x86_64/fdio/vpp/vpp-1710
nfv/x86_64/fdio/vpp/vpp-1801
nfv/x86_64/fdio/vpp/vpp-1804
nfv/x86_64/fdio/vpp/vpp-1807
opstools/x86_64/common
opstools/x86_64/fluentd
opstools/x86_64/logging
opstools/x86_64/perfmon
opstools/x86_64/sensu
paas/x86_64/openshift-origin
paas/x86_64/openshift-origin13
paas/x86_64/openshift-origin14
paas/x86_64/openshift-origin15
paas/x86_64/openshift-origin36
paas/x86_64/openshift-origin37
paas/x86_64/openshift-origin38
paas/x86_64/openshift-origin39
paas/x86_64/openshift-origin310
sclo/x86_64/rh/devassist09
sclo/x86_64/rh/devtoolset-3
sclo/x86_64/rh/devtoolset-4
sclo/x86_64/rh/devtoolset-6
sclo/x86_64/rh/devtoolset-7
sclo/x86_64/rh/git19
sclo/x86_64/rh/go-toolset-7
sclo/x86_64/rh/httpd24
sclo/x86_64/rh/llvm-toolset-7
sclo/x86_64/rh/mariadb55
sclo/x86_64/rh/maven30
sclo/x86_64/rh/mongodb24
sclo/x86_64/rh/mysql55
sclo/x86_64/rh/nginx16
sclo/x86_64/rh/nodejs010
sclo/x86_64/rh/passenger40
sclo/x86_64/rh/perl516
sclo/x86_64/rh/php54
sclo/x86_64/rh/php55
sclo/x86_64/rh/postgresql92
sclo/x86_64/rh/python27
sclo/x86_64/rh/python33
sclo/x86_64/rh/python34
sclo/x86_64/rh/rh-eclipse46
sclo/x86_64/rh/rh-git29
sclo/x86_64/rh/rh-haproxy18
sclo/x86_64/rh/rh-java-common
sclo/x86_64/rh/rh-mariadb100
sclo/x86_64/rh/rh-mariadb101
sclo/x86_64/rh/rh-mariadb102
sclo/x86_64/rh/rh-maven33
sclo/x86_64/rh/rh-maven35
sclo/x86_64/rh/rh-mongodb26
sclo/x86_64/rh/rh-mongodb30upg
sclo/x86_64/rh/rh-mongodb32
sclo/x86_64/rh/rh-mongodb34
sclo/x86_64/rh/rh-mongodb36
sclo/x86_64/rh/rh-mysql56
sclo/x86_64/rh/rh-mysql57
sclo/x86_64/rh/rh-nginx18
sclo/x86_64/rh/rh-nginx110
sclo/x86_64/rh/rh-nginx112
sclo/x86_64/rh/rh-nodejs4
sclo/x86_64/rh/rh-nodejs6
sclo/x86_64/rh/rh-nodejs8

Re: [CentOS-virt] We need a patch in the kernel for tpm

[George Dunlap]

On Thu, Sep 13, 2018 at 1:42 PM Dag Nygren  wrote:
>
> On torsdag 13 september 2018 kl. 12:58:03 EEST George Dunlap wrote:
> > Dag,
> >
>
> Just verified after a lengthy compilation of the kernel
> that the patch really works and now I can see a TPM on
> the virtual side!

Great!

> > Thanks for tracking this down.  Any chance you could send a PR to
> > https://github.com/CentOS-virt7/xen-kernel?
>
> I will definitely join that mailing list. Have a feeling this is not the
> last problem I will see :-)
>
> > Otherwise, Anthony or I will take a look when we get a chance.
>
> But I would appreciate it if somebody used to the
> procedures would pick it up from here.

It's not a mailing list, it's the public git repo for the xen kernel
packages. :-)

As I said, Anthony or I will probably do it at some point (and I've
also forwarded your mail to the upstream Linux Xen maintainers).  But
you sending a PR accomplishes a few things:

1. It gets things there faster
2. It gets you more familiar with the CentOS workflow, so that you can
more easily send improvements / fixes in the future. :-)

 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

Re: [CentOS-virt] ANNOUNCE: centos-release-xen switching to 4.8 next week

[George Dunlap]

On Thu, Aug 2, 2018 at 11:58 AM T.Weyergraf  wrote:
>
> Hi
>
> Thanks for providing updated Packages, they are much appreciated. At
> work, we are currently running an entire production infrastructure on
> Xen4CentOS, with quite some success.
>
> We are looking into a refresh towards CentOS 7 along with newer Xen and
> Dom0 Kernel packages. However, even the updated packages are quite old.
> Xen 4.8 is out of active support since June and will see the end of
> security support in less than a year. Likewise, a newer LTS kernel
> (4.14) exists for quite some time, while the Xen4CentOS effort currently
> uses 4.9.

Re Xen, our ideal goal is to always be running the most
recently-released even-numbered point release; i.e., I would ideally
like to be on 4.10 now, and probably be on 4.12 as soon as 4.12.1
comes out.  But Anthony and I are normal developers with lots of stuff
to do, so we get to it when we can.  Pull requests make improvements
happen much faster. : -)

Regarding Linux, I don't personally have any preference; historically
the sense was that CentOS users liked "old stodgy and boring", and so
staying on the oldest possible kernel to pick up the latest bug fixes
*without* picking up the latest bugs was seen as the thing to do.  We
might make an exception to get PVH.  Did you have an alternate
suggestion for the community to consider?

> Are there any short to mid-term plans to bump both versions to more
> current ones (i.e.: 4.10 and 4.14)? Currently, our update-tests are
> based on 4.10 candidate packages with kernel 4.9. Given the support
> timelines, I'd rather prefer 4.10 over 4.8. A change in Xen versions has
> been never successfully performed using live-migration between versions,
> so a reboot of more or less our entire infrastructure is required.
> Something you would not consider light-hearted.

Supporting any -> any live migration is a testing load that upstream
Xen doesn't have yet.  If that's important, you might consider one of
the paid-for options, like XenServer.

> As a side note, is there anything reasonable, people like me could to,
> to support the speed-up of that process? I would consider testing to be
> important, but are there any regression test-suites, one could use? I am
> aware, there are such tests, but I have not found something to actually
> try in our test-infrastructure.

There are three general things that need testing:
1) Xen core virtualization
  1a) Xen / CentOS package usability
2) CentOS packaging (making sure installs / updates work, )
3) Kernel testing -- device driver bugs, 

#1 is generally taken care of pretty well by upstream testing at this
point, so doesn't need any coverage.

#1a of course is something that is difficult for upstream developers
to do, because we're too close things, and because we don't do
everything our users do.

#2 is something that we really should get into a CI somewhere; but
generally a combination of ad-hoc and community testing seems to work
OK.

#3 is something that it's not really possible for anyone to do other
than a company with massive amounts of dedicated resources and an HCL;
we really rely on our users to test their own hardware and report /
help track down issues.

So, probably the best thing is to help test out new kernels on your
own hardware whenever you can; and also give feedback / suggestions on
the usability of the software and packages that we can feed in to
improve the process.

> Finally a big shout-out and kudos to the Xen community and Xen4CentOS.
> Your work is used and much appreciated.

Thanks!  Glad to know it's useful. :-)

 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

Re: [CentOS-virt] We need a patch in the kernel for tpm

[George Dunlap]

Dag,

Thanks for tracking this down.  Any chance you could send a PR to
https://github.com/CentOS-virt7/xen-kernel?

Otherwise, Anthony or I will take a look when we get a chance.

Peace,
 -George

On Thu, Sep 13, 2018 at 10:41 AM Dag Nygren  wrote:
>
> Hi!
>
> Think I found a reference to the problem(s) I am seeing with
> xen-tpmfront in my setup on the net:
>
> https://patchwork.kernel.org/patch/9485637/
>
> This patch has not been officially entered and it is not
> included in the kernel provided in SIG virt either
>
> Can we please get it in ?
>
> Best
> Dag
>
>
>
> ___
> CentOS-virt mailing list
> CentOS-virt@centos.org
> https://lists.centos.org/mailman/listinfo/centos-virt
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

[CentOS-virt] Virt SIG meetings in August

[George Dunlap]

FYI, I won't be around for the Virt SIG meetings on 21 August or 4
September.  Does anyone want to step up and chair those, or should we
just take a summer holiday and cancel them?

 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

Re: [CentOS-virt] libvirtd hang on CentOS6 after latest updates

[George Dunlap]

Karel,

Thanks for the detailed report.  Would you mind re-posting this to the
xen-devel mailing list?

Thanks,
 -Georeg

On Thu, May 24, 2018 at 9:47 AM, Karel Hendrych  wrote:
> Bump. Folks, any ideas?
>
> Cheers
> Karel
>
>
> On 22.5.2018 11:33, Karel Hendrych wrote:
>>
>> Hi, I am seeing frequent libvirtd hangs (clients not responding) after
>> last CentOS6-Xen update :
>>
>> libvirt-libs-4.1.0-2.xen46.el6.x86_64
>> libvirt-daemon-4.1.0-2.xen46.el6.x86_64
>> libvirt-daemon-driver-network-4.1.0-2.xen46.el6.x86_64
>> libvirt-daemon-driver-nwfilter-4.1.0-2.xen46.el6.x86_64
>> libgcc-4.4.7-18.el6_9.2.x86_64
>> 2:qemu-img-0.12.1.2-2.503.el6_9.5.x86_64
>> libvirt-daemon-driver-storage-core-4.1.0-2.xen46.el6.x86_64
>> libvirt-daemon-driver-secret-4.1.0-2.xen46.el6.x86_64
>> libvirt-daemon-driver-interface-4.1.0-2.xen46.el6.x86_64
>> libvirt-daemon-driver-nodedev-4.1.0-2.xen46.el6.x86_64
>> 10:centos-release-xen-common-8-4.el6.x86_64
>> xen-licenses-4.6.6-12.el6.x86_64
>> xen-libs-4.6.6-12.el6.x86_64
>> libvirt-daemon-driver-libxl-4.1.0-2.xen46.el6.x86_64
>> libvirt-daemon-driver-xen-4.1.0-2.xen46.el6.x86_64
>> libvirt-daemon-driver-qemu-4.1.0-2.xen46.el6.x86_64
>> libvirt-daemon-driver-storage-gluster-4.1.0-2.xen46.el6.x86_64
>> libvirt-daemon-driver-storage-logical-4.1.0-2.xen46.el6.x86_64
>> libvirt-daemon-driver-storage-mpath-4.1.0-2.xen46.el6.x86_64
>> libvirt-daemon-driver-storage-disk-4.1.0-2.xen46.el6.x86_64
>> libvirt-daemon-driver-storage-scsi-4.1.0-2.xen46.el6.x86_64
>> libvirt-daemon-driver-storage-iscsi-4.1.0-2.xen46.el6.x86_64
>> libvirt-daemon-driver-storage-4.1.0-2.xen46.el6.x86_64
>> libstdc++-4.4.7-18.el6_9.2.x86_64
>> libvirt-daemon-config-nwfilter-4.1.0-2.xen46.el6.x86_64
>> libvirt-daemon-config-network-4.1.0-2.xen46.el6.x86_64
>> libvirt-daemon-driver-lxc-4.1.0-2.xen46.el6.x86_64
>> libvirt-client-4.1.0-2.xen46.el6.x86_64
>> linux-firmware-20171215-82.git2451bb22.el6.noarch
>> 12:dhcp-common-4.1.1-53.P1.el6.centos.4.x86_64
>> 12:dhclient-4.1.1-53.P1.el6.centos.4.x86_64
>> libvirt-4.1.0-2.xen46.el6.x86_64
>> 10:centos-release-xen-46-8-4.el6.x86_64
>> 10:centos-release-xen-44-8-4.el6.x86_64
>> tzdata-2018e-3.el6.noarch
>> libgomp-4.4.7-18.el6_9.2.x86_64
>> kernel-4.9.86-30.el6.x86_64
>> xen-hypervisor-4.6.6-12.el6.x86_64
>> xen-runtime-4.6.6-12.el6.x86_64
>> xen-4.6.6-12.el6.x86_64
>> libvirt-daemon-xen-4.1.0-2.xen46.el6.x86_64
>>
>> Remedy is to kill -9 libvirtd and start again. Issue can be replicated
>> within few domU starts. Usually libvirtd hangs when domU is bringing up xen
>> drivers or something around udev, like:
>>
>> xen_netfront: Initialising Xen virtual ethernet driver
>>
>> I've been looking into libvirtd strace and debug logs, so far most
>> suspicious in libvirtd debug log is this:
>>
>> libvirtd.log:2018-05-22 08:32:44.760+: 25455: debug :
>> udevRemoveOneDevice:1289 : Failed to find device to remove that has udev
>> name '/sys/devices/vif-24-0/net/vif24.0/queues/tx-7'
>> libvirtd.log:2018-05-22 08:32:44.761+: 25455: debug :
>> udevRemoveOneDevice:1289 : Failed to find device to remove that has udev
>> name '/sys/devices/vif-24-0/net/vif24.0/queues/tx-6'
>> libvirtd.log:2018-05-22 08:32:44.761+: 25455: debug :
>> udevRemoveOneDevice:1289 : Failed to find device to remove that has udev
>> name '/sys/devices/vif-24-0/net/vif24.0/queues/tx-4'
>> libvirtd.log:2018-05-22 08:32:44.762+: 25455: debug :
>> udevRemoveOneDevice:1289 : Failed to find device to remove that has udev
>> name '/sys/devices/vif-24-0/net/vif24.0/queues/tx-5'
>> libvirtd.log:2018-05-22 08:32:44.763+: 25455: debug :
>> udevRemoveOneDevice:1289 : Failed to find device to remove that has udev
>> name '/sys/devices/vif-24-0/net/vif24.0/queues/tx-2'
>> libvirtd.log:2018-05-22 08:32:44.764+: 25455: debug :
>> udevRemoveOneDevice:1289 : Failed to find device to remove that has udev
>> name '/sys/devices/vif-24-0/net/vif24.0/queues/tx-3'
>> libvirtd.log:2018-05-22 08:32:44.765+: 25455: debug :
>> udevRemoveOneDevice:1289 : Failed to find device to remove that has udev
>> name '/sys/devices/vif-24-0/net/vif24.0/queues/rx-6'
>> libvirtd.log:2018-05-22 08:32:44.766+: 25455: debug :
>> udevRemoveOneDevice:1289 : Failed to find device to remove that has udev
>> name '/sys/devices/vif-24-0/net/vif24.0/queues/rx-5'
>> libvirtd.log:2018-05-22 08:32:44.767+: 25455: debug :
>> udevRemoveOneDevice:1289 : Failed to find device to remove that has udev
>> name '/sys/devices/vif-24-0/net/vif24.0/queues/rx-4'
>> libvirtd.log:2018-05-22 08:32:44.767+: 25455: debug :
>> udevRemoveOneDevice:1289 : Failed to find device to remove that has udev
>> name '/sys/devices/vif-24-0/net/vif24.0/queues/rx-7'
>> libvirtd.log:2018-05-22 08:32:44.768+: 25455: debug :
>> udevRemoveOneDevice:1289 : Failed to find device to remove that has udev
>> name '/sys/devices/vif-24-0/net/vif24.0/queues/rx-2'
>> libvirtd.log:2018-05-22 08:32:44.769+: 25455: debug :
>> udevRemoveOneDevice:1289 : Failed to find 

Re: [CentOS-virt] Xen DomU's randomly freezing

[George Dunlap]

On Mon, Apr 30, 2018 at 1:08 PM, Daz Day  wrote:
> Hi,
>
> I've tried hitting up the CentOS forums and thought I'd try here too as I
> don't seem to be getting any bites.
>
> We've been in the process of migrating all our hypervisors over to CentOS 7
> using Xen. Once we had a few up and running we started to notice that the
> DomU's would randomly freeze. They become unresponsive to any network
> traffic, stop consuming CPU resources on the hypervisor and it's not
> possible to log in to the console locally using:
> virsh console 
> We can sometimes get as far as typing a username and hitting return, but the
> DomU just hangs there. It doesn't seem to matter what Linux distro the DomU
> is running, it affects them all. The only way we can get them back is by
> destroying and recreating them (far from ideal!).
>
> After a bit of research and digging around, we eventually found these 2
> nuggets:
> https://wiki.gentoo.org/wiki/Xen#Xen_domU_hanging_with_kernel_4.3.2B
> https://www.novell.com/support/kb/doc.php?id=7018590
>
> They both advise adding the command line argument:
> gnttab_max_frames=256(the default is 32).
> We applied this change and all hypervisors rand stable for around a week
> until DomU's started freezing again (we've since tried even higher values,
> to no avail). More research later led me to
> https://bugs.centos.org/view.php?id=14258 and
> https://bugs.centos.org/view.php?id=14284 (which are essentially the same
> report). There hasn't really been any movement on these tickets
> unfortunately, but I have +1'd them.
>
> Have any others had issues with Xen and DomU's locking up in CentOS 7? Are
> there any other fixes/workarounds? If any additional info is needed that
> isn't already in the bug tickets or forum post, please let me know and I'll
> be happy to provide whatever is required (these freezes are happening at
> least once a day).
>
> Any help would be much appreciated and would mean my Ops guys could get a
> decent sleep!
> Cheers
> Darren

Darren,

Would you mind reposting this to xen-users, along with:

* The config file for your guests
* The output of `dmesg` from inside one of the guests before it hangs
* The output of `dmesg` run on your dom0 after one of these machine hangs

Thanks,
 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

Re: [CentOS-virt] Proposal to CANCEL: 2018-05-01 Virtualization SIG meeting

[George Dunlap]

On Tue, Apr 24, 2018 at 4:41 PM, Sandro Bonazzola 
wrote:

> Hi, I'm proposing to cancel next week meeting.
> It's labor day in many countries including Italy.
>

Fine with me.  If anyone has any issues feel free to raise them here or on
#centos or #centos-virt.

 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

Re: [CentOS-virt] custom Xen on custom kernel on CentOS 7

[George Dunlap]

On Tue, Feb 27, 2018 at 3:50 PM, John Vetter  wrote:
> Hi,
>
> I'm trying to run an arbitrary Xen version (4.7.x) on a recent kernel (say,
> 4.13.x) on CentOS 7.
>
> What is the recommended way for doing this? (I am new to Xen and
> virtualization).
>
> I tried the following:
> 1. installed xen4centos.
> 2. built linux kernel 4.13.x and installed it (using make install)
> 3. built xen 4.7.x and installed it (using make install).
>
> grub2-mkconfig and grub-bootxen.sh don't seem to be picking up the
> combination of new kernel and new xen and making an entry in the grub.cfg
> file.

On systems with grub2, grub-bootxen.sh is tweaking the global grub2
config -- making sure Xen runs first, and adding some default
configuration.  Even without that, grub2-mkconfig should be creating
entries if the binaries exist.

Are you sure:
1. That your new kernel & hypervisor have installed binaries in /boot?
2. That grub2-mkconfig is writing the config to the proper directory?
(i.e., that, you're using the correct '-o' argument?)

 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

Re: [CentOS-virt] Xen 4.6.6-9 (with XPTI meltdown mitigation) packages making their way to centos-virt-xen-testing

[George Dunlap]

On Mon, Jan 22, 2018 at 10:38 PM, Nathan March  wrote:
> Just a heads up that I'm seeing major stability problems on these builds.
> Didn't have  console capture setup unfortunately, but have seen my test
> hypervisor hard lock twice over the weekend.
>
> This is with xpti being used, rather than the shim.

Thanks for the heads-up.  It's been running through XenServer's tests
as well as the XenProject's "osstest" -- I haven't heard of any
additional issues, but I'll ask.

It's possible also that it's some interaction between the specific
CentOS environment -- the gcc version, the particular dom0 kernel, 
I'll ask Anthony if he can run the CentOS packages through osstest and
see if anything comes up.

 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

Re: [CentOS-virt] Xen 4.4 Immediate EOL

[George Dunlap]

On Fri, Jan 19, 2018 at 12:17 PM, Pasi Kärkkäinen  wrote:
> On Thu, Jan 18, 2018 at 11:48:35AM -0600, Kevin Stange wrote:
>> Hi,
>>
>
> Hi,
>
>> I am very sorry to do this on short notice, but obviously Meltdown and
>> Spectre are a lot more than anyone was really expecting to come down the
>> pipeline.  Xen 4.4 has been EOL upstream for about a year now and I have
>> personally been reviewing and backporting patches based on the 4.5
>> versions made available upstream.
>>
>> Given that 4.5 is now also reaching EOL, backporting to 4.4 will become
>> harder and I've already taken steps to vacate 4.4 in my own environment
>> ASAP.  Spectre and Meltdown patches most likely will only officially
>> reach 4.6 and are very complicated.  Ultimately, I don't think this is a
>> constructive use of my time.  Therefore, I will NOT be continuing to
>> provide updated Xen 4.4 builds any longer through CentOS Virt SIG.  If
>> someone else would like to take on the job, you're welcome to try.  Pop
>> by #centos-virt on Freenode to talk to us there if you're interested.
>>
>> For short term mitigation of the Meltdown issue on 4.4 with PV domains,
>> your best bet is probably to use the "Vixen" shim solution, which George
>> has put into the xen-44 package repository per his email from two days
>> ago. Vixen allows you to run PV domains inside HVM guest containers.  It
>> does not protect the guest from itself, but protects the domains from
>> each other.  Long term, your best bet is to try to get up to a new
>> version of Xen that is under upstream security support, probably 4.8.
>>
>
> Oracle VM 3.4 product is based on Xen 4.4, and they seem to have backported 
> the fixes already..
>
> It looks like those src.rpms have {CVE-2017-5753} {CVE-2017-5715} 
> {CVE-2017-5754} fixes included.

Example patch description:

x86/cpuid: Offer Indirect Branch Controls to guests (Andrew Cooper)
[Orabug: 27344753]  {CVE-2017-5753} {CVE-2017-5715} {CVE-2017-5754}

That patch, however, only has to do with 5715, not 5753 or 5754.  It
looks like it's tagged with "Orabug xxx", which covers all three
variants, so their system automatically tags it with all three CVEs.

It looks like they've taken an early version of the SP2 mitigation
(which has been posted publicly), cleaned it up, and backported it
(along with prerequisites).  Official patches are still in progress.

 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

Re: [CentOS-virt] "Vixen" HVM shim package available in virt-xen-testing

[George Dunlap]

On Tue, Jan 16, 2018 at 10:45 AM, George Dunlap <dunl...@umich.edu> wrote:
> To install the package:
>
>  yum --enablerepo=virt-xen-VV-testing xen-vixen
>
> Where VV is '44', '46', or '48', depending on which version you're
> using.   (It's the same package for all versions.)
>
> This will install the xen-vixen "shim" binary, as well as the
> pvshim-converter script.
>
> See XSA-254 [1] for detailed information about who should use it, why,
> and when.  Please report both successes and failures here. :-)

The package is missing two dependencies, without which the script
won't run: mformat and xorriso.  xorriso is only available from EPEL.

So to use the script, enable EPEL (if you haven't already):

yum install -y epel-release

Then install the two prerequisites:

yum install -y mformat xorriso

I'll add the mformat dependency, and see what I can do about xorriso.

 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

[CentOS-virt] Xen 4.6.6-9 (with XPTI meltdown mitigation) packages making their way to centos-virt-xen-testing

[George Dunlap]

I've built & tagged packages for CentOS 6 and 7 4.6.6-9, with XPTI
"stage 1" Meltdown mitigation.

This will allow 64-bit PV guests to run safely (with a few caveats),
but incurs a fairly significant slowdown for 64-bit PV guests on Intel
boxes (including domain 0).

If you prefer using Vixen / Comet, you can turn it off by adding
'xpti=0' to your Xen command-line.

Detailed information can be found in the XSA-254 advisory:

https://xenbits.xen.org/xsa/advisory-254.html

Please test and report any issues you have.  I'll probably tag then
with -release tomorrow.

4.8 packages should be coming to buildlogs soon.

 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

[CentOS-virt] "Vixen" HVM shim package available in virt-xen-testing

[George Dunlap]

To install the package:

 yum --enablerepo=virt-xen-VV-testing xen-vixen

Where VV is '44', '46', or '48', depending on which version you're
using.   (It's the same package for all versions.)

This will install the xen-vixen "shim" binary, as well as the
pvshim-converter script.

See XSA-254 [1] for detailed information about who should use it, why,
and when.  Please report both successes and failures here. :-)

-George

[1] https://xenbits.xen.org/xsa/advisory-254.html
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

Re: [CentOS-virt] CentOS-virt - Kernel Side-Channel Attacks

[George Dunlap]

On Thu, Jan 4, 2018 at 7:12 PM, Sarah Newman  wrote:
> On 01/04/2018 10:49 AM, Akemi Yagi wrote:
>> On Thu, Jan 4, 2018 at 9:51 AM,  wrote:
>>
>>> Please patch the CentOS-virt Kernel to fix the
>>> Kernel Side-Channel Attacks vulnerabilities.
>>>
>>> The latest CentOS-virt kernel was released in November, as seen below.
>>>
>>> kernel-4.9.63-29.el7.x86_64.rpm 2017-11-21 13:30
>>>
>>> https://access.redhat.com/security/vulnerabilities/speculativeexecution
>>> http://mirror.centos.org/centos/7/virt/x86_64/xen/
>>>
>>
>> As far as I can see, the patches for
>> KAISER (Kernel Address
>> Isolation to have Side-channels Efficiently Removed) will appear in
>> kernel 4.9.75. Looks like it will be released soon upstream (kernel.org).
>>
>
> To my best knowledge KAISER doesn't matter for Xen Dom0's given they run in 
> PV mode, and KAISER isn't enabled for PV guests.

But it will be important if anyone is running the CentOS kernel in
their HVM domUs (as guest kernels can be attacked using SP3 by guest
user space without the KPTI patches).

I'm sure Johnny will get to it as soon as he has the opportunity.

 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

Re: [CentOS-virt] Proposal to CANCEL: 2017-12-26 Virt SIG meeting

[George Dunlap]

I proposed this at the last virt sig meeting and nobody objected.

I certainly won't be around on 26 December. :-)

 -George

On Mon, Dec 18, 2017 at 3:11 PM, Sandro Bonazzola 
wrote:

> Hi folks, I'm proposing to cancel the Virt SIG meeting on December 26th
> due to Holidays.
> If you're aware of anything important we have to discuss next week,
> please do reply to
> this mail. Thanks!
>
> --
>
> SANDRO BONAZZOLA
>
> ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R
>
> Red Hat EMEA 
> 
> TRIED. TESTED. TRUSTED. 
>
>
> ___
> CentOS-virt mailing list
> CentOS-virt@centos.org
> https://lists.centos.org/mailman/listinfo/centos-virt
>
>
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

Re: [CentOS-virt] Xen PV DomU running Kernel 4.14.5-1.el7.elrepo.x86_64: xl -v vcpu-set triggers domU kernel WARNING, then domU becomes unresponsive

[George Dunlap]

Adi,

Thanks for your detailed report -- would you mind reposting this to
xen-de...@lists.xenproject.org?  This looks like a general Xen / Linux
bug (not specific to the Virt SIG packages), and there are a lot more
eyeballs there.

Thanks,
 -George


On Tue, Dec 12, 2017 at 12:52 AM, Adi Pircalabu  wrote:
> Has anyone seen this recently? I couldn't replicate it on:
> - CentOS 6 running kernel-2.6.32-696.16.1.el6.x86_64,
> kernel-lt-4.4.105-1.el6.elrepo.x86_64
> - CentOS 7 running 4.9.67-1.el7.centos.x86_64
>
> But I can replicate it consistently running "xl -v vcpu-set  "
> on:
> - CentOS 6 running 4.14.5-1.el6.elrepo.x86_64
> - CentOS 7 running 4.14.5-1.el7.elrepo.x86_64
>
> dom0 versions tested with similar results in the domU:
> - 4.6.6-6.el7 on kernel 4.9.63-29.el7.x86_64
> - 4.6.3-15.el6 on kernel 4.9.37-29.el6.x86_64
>
> Noticed behaviour:
> - These commands stall:
> top
> ls -l /var/tmp
> ls -l /tmp
> - Stuck in D state on the CentOS 7 domU:
> root 5  0.0  0.0  0 0 ?D11:20   0:00
> [kworker/u8:0]
> root   316  0.0  0.0  0 0 ?D11:20   0:00
> [jbd2/xvda1-8]
> root  1145  0.0  0.2 116636  4776 ?Ds   11:20   0:00 -bash
> root  1289  0.0  0.1  25852  2420 ?Ds   11:35   0:00
> /usr/bin/systemd-tmpfiles --clean
> root  1290  0.0  0.1 125248  2696 pts/1D+   11:44   0:00 ls
> --color=auto -l /tmp/
> root  1293  0.0  0.1 125248  2568 pts/2D+   11:44   0:00 ls
> --color=auto -l /var/tmp
> root  1296  0.0  0.2 116636  4908 pts/3Ds+  11:44   0:00 -bash
> root  1358  0.0  0.1 125248  2612 pts/4D+   11:47   0:00 ls
> --color=auto -l /var/tmp
>
> At a first glance it appears the issue is in 4.14.5 kernel. Stack traces
> follow:
>
> -CentOS 6 kernel-ml-4.14.5-1.el6.elrepo.x86_64 start here-
> [ cut here ]
> WARNING: CPU: 4 PID: 60 at block/blk-mq.c:1144
> __blk_mq_run_hw_queue+0x9e/0xc0
> Modules linked in: intel_cstate(-) ipt_REJECT nf_reject_ipv4
> nf_conntrack_ipv4 nf_defrag_ipv4 xt_multiport iptable_filter ip_tables
> ip6t_REJECT nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 xt_state
> nf_conntrack libcrc32c ip6table_filter ip6_tables dm_mod dax xen_netfront
> crc32_pclmul crct10dif_pclmul ghash_clmulni_intel crc32c_intel pcbc
> aesni_intel glue_helper crypto_simd cryptd aes_x86_64 coretemp hwmon
> x86_pkg_temp_thermal sb_edac intel_rapl_perf pcspkr ext4 jbd2 mbcache
> xen_blkfront
> CPU: 4 PID: 60 Comm: kworker/4:1H Not tainted 4.14.5-1.el6.elrepo.x86_64 #1
> Workqueue: kblockd blk_mq_run_work_fn
> task: 8802711a2780 task.stack: c90041af4000
> RIP: e030:__blk_mq_run_hw_queue+0x9e/0xc0
> RSP: e02b:c90041af7c48 EFLAGS: 00010202
> RAX: 0001 RBX: 88027117fa80 RCX: 0001
> RDX: 88026b053ee0 RSI: 88027351bca0 RDI: 88026b072800
> RBP: c90041af7c68 R08: c90041af7eb8 R09: 8802711a2810
> R10: 7ff0 R11: 0001 R12: 88026b072800
> R13: e8d04d00 R14:  R15: e8d04d05
> FS:  2b7b7c89b700() GS:88027350() knlGS:
> CS:  e033 DS:  ES:  CR0: 80050033
> CR2: ff600400 CR3: 00026d953000 CR4: 00042660
> Call Trace:
>  blk_mq_run_work_fn+0x31/0x40
>  process_one_work+0x174/0x440
>  ? xen_mc_flush+0xad/0x1b0
>  ? schedule+0x3a/0xa0
>  worker_thread+0x6b/0x410
>  ? default_wake_function+0x12/0x20
>  ? __wake_up_common+0x84/0x130
>  ? maybe_create_worker+0x120/0x120
>  ? schedule+0x3a/0xa0
>  ? _raw_spin_unlock_irqrestore+0x16/0x20
>  ? maybe_create_worker+0x120/0x120
>  kthread+0x111/0x150
>  ? __kthread_init_worker+0x40/0x40
>  ret_from_fork+0x25/0x30
> Code: 89 df e8 06 2f d9 ff 4c 89 e7 41 89 c5 e8 0b 6e 00 00 44 89 ee 48 89
> df e8 20 2f d9 ff 48 8b 5d e8 4c 8b 65 f0 4c 8b 6d f8 c9 c3 <0f> ff eb aa 4c
> 89 e7 e8 e6 6d 00 00 48 8b 5d e8 4c 8b 65 f0 4c
> ---[ end trace fe2aaf4e723042fd ]---
> -CentOS 6 kernel-ml-4.14.5-1.el6.elrepo.x86_64 end here-
>
> -CentOS 7 kernel-ml-4.14.5-1.el7.elrepo.x86_64 start here-
> [  116.528885] [ cut here ]
> [  116.528894] WARNING: CPU: 3 PID: 38 at block/blk-mq.c:1144
> __blk_mq_run_hw_queue+0x89/0xa0
> [  116.528898] Modules linked in: intel_cstate(-) ip_set_hash_ip ip_set
> nfnetlink x86_pkg_temp_thermal coretemp crct10dif_pclmul crc32_pclmul
> ghash_clmulni_intel pcbc aesni_intel crypto_simd glue_helper cryptd
> intel_rapl_perf pcspkr nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables
> ext4 mbcache jbd2 xen_netfront xen_blkfront crc32c_intel
> [  116.528919] CPU: 3 PID: 38 Comm: kworker/3:1H Not tainted
> 4.14.5-1.el7.elrepo.x86_64 #1
> [  116.529007] Code: 00 e8 7c c5 45 00 4c 89 e7 e8 14 4b d7 ff 48 89 df 41
> 89 c5 e8 19 66 00 00 44 89 ee 4c 89 e7 e8 2e 4b d7 ff 5b 41 5c 41 5d 5d c3
> <0f> ff eb b4 48 89 df e8 fb 65 00 00 5b 41 5c 41 5d 5d c3 0f ff
> [  116.529034] ---[ end trace a7814e3ec9a330c6 ]---
> [  

Re: [CentOS-virt] Xen 4.6.6-8 in virt-testing

[George Dunlap]

Great -- I also managed to do some testing, and so tagged it for
release earlier today.  Should get picked up in the signing run
tomorrow.

 -George

On Wed, Dec 13, 2017 at 3:58 PM, Johnny Hughes <joh...@centos.org> wrote:
> George,
>
> This version of xen updates and allows both a CentOS 6 and CentOS 7 DomU
> to start and run in both HVM and PVHVM modes.  So it 'works for me'.
>
> Thanks,
> Johnny Hughes
>
> On 12/12/2017 08:34 AM, George Dunlap wrote:
>> Xen 4.6.6-8 has been tagged in virt-testing.  It contains XSAs
>> 248-251, as well as an additional fix to XSA 240.  Please test it if
>> you get a chance and report any bugs; I'll probably push it to mirrors
>> tomorrow if I don't hear anything.
>
>
> ___
> CentOS-virt mailing list
> CentOS-virt@centos.org
> https://lists.centos.org/mailman/listinfo/centos-virt
>
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

Re: [CentOS-virt] Stability issues since moving to 4.6 - Kernel paging request bug + VM left in null state

[George Dunlap]

Natan,

Thanks for the report.  Would you mind re-posting this to the
xen-users mailing list?  You're much more likely to get someone there
who's seen such a bug before.

 -George

On Tue, Nov 7, 2017 at 11:12 PM, Nathan March  wrote:
> Since moving from 4.4 to 4.6, I’ve been seeing an increasing number of
> stability issues on our hypervisors. I’m not clear if there’s a singular
> root cause here, or if I’m dealing with multiple bugs…
>
>
>
> One of the more common ones I’ve seen, is a VM on shutdown will remain in
> the null state and a kernel bug is thrown:
>
>
>
> xen001 log # xl list
>
> NameID   Mem VCPUs  State
> Time(s)
>
> Domain-0 0  614424 r-
> 6639.7
>
> (null)   3 0 1 --pscd
> 36.3
>
>
>
> [89920.839074] BUG: unable to handle kernel paging request at
> 88020ee9a000
>
> [89920.839546] IP: [] __memcpy+0x12/0x20
>
> [89920.839933] PGD 2008067
>
> [89920.840022] PUD 17f43f067
>
> [89920.840390] PMD 1e0976067
>
> [89920.840469] PTE 0
>
> [89920.840833]
>
> [89920.841123] Oops:  [#1] SMP
>
> [89920.841417] Modules linked in: ebt_ip ebtable_filter ebtables
> arptable_filter arp_tables bridge xen_pciback xen_gntalloc nfsd auth_rpcgss
> nfsv3 nfs_acl nfs fscache lockd sunrpc grace 8021q mrp garp stp llc bonding
> xen_acpi_processor blktap xen_netback xen_blkback xen_gntdev xen_evtchn
> xenfs xen_privcmd dcdbas fjes pcspkr ipmi_devintf ipmi_si ipmi_msghandler
> joydev i2c_i801 i2c_smbus lpc_ich shpchp mei_me mei ioatdma ixgbe mdio igb
> dca ptp pps_core uas usb_storage wmi ttm
>
> [89920.847080] CPU: 4 PID: 1471 Comm: loop6 Not tainted 4.9.58-29.el6.x86_64
> #1
>
> [89920.847381] Hardware name: Dell Inc. PowerEdge C6220/03C9JJ, BIOS 2.7.1
> 03/04/2015
>
> [89920.847893] task: 8801b75e0700 task.stack: c900460e
>
> [89920.848192] RIP: e030:[]  []
> __memcpy+0x12/0x20
>
> [89920.848783] RSP: e02b:c900460e3b20  EFLAGS: 00010246
>
> [89920.849081] RAX: 88018916d000 RBX: 8801b75e0700 RCX:
> 0200
>
> [89920.849384] RDX:  RSI: 88020ee9a000 RDI:
> 88018916d000
>
> [89920.849686] RBP: c900460e3b38 R08: 88011da9fcf8 R09:
> 0002
>
> [89920.849989] R10: 88019535bddc R11: ea0006245b5c R12:
> 1000
>
> [89920.850294] R13: 88018916e000 R14: 1000 R15:
> c900460e3b68
>
> [89920.850605] FS:  7fb865c30700() GS:880204b0()
> knlGS:
>
> [89920.851118] CS:  e033 DS:  ES:  CR0: 80050033
>
> [89920.851418] CR2: 88020ee9a000 CR3: 0001ef03b000 CR4:
> 00042660
>
> [89920.851720] Stack:
>
> [89920.852009]  814375ca c900460e3b38 c900460e3d08
> c900460e3bb8
>
> [89920.852821]  814381c5 c900460e3b68 c900460e3d08
> 1000
>
> [89920.853633]  c900460e3d88  1000
> ea00
>
> [89920.854445] Call Trace:
>
> [89920.854741]  [] ? memcpy_from_page+0x3a/0x70
>
> [89920.855043]  []
> iov_iter_copy_from_user_atomic+0x265/0x290
>
> [89920.855354]  [] generic_perform_write+0xf3/0x1d0
>
> [89920.855673]  [] ? xen_load_tls+0xaa/0x160
>
> [89920.855992]  [] nfs_file_write+0xdb/0x200 [nfs]
>
> [89920.856297]  [] vfs_iter_write+0xa2/0xf0
>
> [89920.856599]  [] lo_write_bvec+0x65/0x100
>
> [89920.856899]  [] do_req_filebacked+0x195/0x300
>
> [89920.857202]  [] loop_queue_work+0x5b/0x80
>
> [89920.857505]  [] kthread_worker_fn+0x98/0x1b0
>
> [89920.857808]  [] ? schedule+0x3a/0xa0
>
> [89920.858108]  [] ? _raw_spin_unlock_irqrestore+0x16/0x20
>
> [89920.858411]  [] ? kthread_probe_data+0x40/0x40
>
> [89920.858713]  [] kthread+0xe5/0x100
>
> [89920.859014]  [] ? __kthread_init_worker+0x40/0x40
>
> [89920.859317]  [] ret_from_fork+0x25/0x30
>
> [89920.859615] Code: 81 f3 00 00 00 00 e9 1e ff ff ff 90 90 90 90 90 90 90
> 90 90 90 90 90 90 90 66 66 90 66 90 48 89 f8 48 89 d1 48 c1 e9 03 83 e2 07
>  48 a5 89 d1 f3 a4 c3 66 0f 1f 44 00 00 48 89 f8 48 89 d1 f3
>
> [89920.864410] RIP  [] __memcpy+0x12/0x20
>
> [89920.864749]  RSP 
>
> [89920.865021] CR2: 88020ee9a000
>
> [89920.865294] ---[ end trace b77d2ce5646284d1 ]---
>
>
>
> Wondering if anyone has advice on how to troubleshoot the above, or might
> have some insight into that the issue could be? This hypervisor was only up
> for a day, had almost no VMs running on it since boot, I booted a single
> windows test VM which BSOD’ed and then this happened.
>
>
>
> This is on xen 4.6.6-4.el6 with 4.9.58-29.el6.x86_64. I see these issues
> across a wide number of systems with from both Dell and Supermicro, although
> we run the same Intel x540 10gb nic’s in each system with the same netapp
> nfs backend storage.
>
>
>
> Cheers,
>
> Nathan
>
>
> ___
> CentOS-virt mailing list
> CentOS-virt@centos.org
> 

[CentOS-virt] 4.6.6-2, with XSAs 226, 227, 228, and 230, in centos-virt-testing

[George Dunlap]

I've built Xen 4.6.6 with the XSAs released last week, and tagged it
so that it shows up in centos-virt-testing.  Please test it and let me
know if you have any problems.

Thanks,
 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

[CentOS-virt] Xen 4.6.3-15 packages, including XSAs 216-219, 221-225 on their way through the build system

[George Dunlap]

Xen 4.6.3-15 packages for CentOS 6 and CentOS 7 are on their way
through the build system.  They should show up in centos-virt-testing
in a few hours, and in the main mirrors tomorrow morning (God
willing).

These contain several critical updates; users are encouraged to update
as soon as possible.

XSA 220 unfortunately had several dependencies on changes included in
4.6.4 and 4.6.5.  This particular vulnerability is slightly lower
priorty; so I have queued up an update to 4.6.5 which includes this
patch.  Once 4.6.3-15 is tagged for release, I'll start building 4.6.5
put it in centos-virt-testing for people to test.

 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

Re: [CentOS-virt] What is the purpose setting console=hvc0 in the dom0 grub config?

[George Dunlap]

On Wed, May 17, 2017 at 4:20 PM, Jerry <jerry...@gmail.com> wrote:
> On Wed, May 17, 2017 at 2:39 AM, George Dunlap <dunl...@umich.edu> wrote:
>>
>> On Wed, May 17, 2017 at 4:26 AM, Jerry <jerry...@gmail.com> wrote:
>> > I always disable "rhgb quiet" on a fresh install because I don't like
>> > boot
>> > messages being hidden from me, and now this other thing does it.  I like
>> > details, I need the details, don't hide them from me.
>>
>> I feel the same way about 'rhgb quiet'.  :-)
>>
>> The 'console=hvc0' setting doesn't hide them from you, it just sends
>> them somewhere you're not looking.
>
>
> I'm looking at the system's console during installation. Sending it
> somewhere else is hiding it from me.
>
>>
>> On bare metal, the console output can typically go two places:
>> 1. The screen
>> 2. A serial port
>>
>> For server applications serial has several advantages over the screen:
>> * You can capture the output to more easily report bugs
>> * If you're capturing it you can keep things that would have scrolled
>> off-screen, or been erased due to a reboot
>> * In a datacenter it's faster, more convenient, and cheaper than an
>> IP-based KVM switch
>
>
> I get what these things are, but not what hvc0 is doing.

See below -- it sends the output to Xen; Xen will then forward it to
the serial, the screen, or both.

> This system has built-in IPMI, the installation was done remotely using it.
>
>>
>> Xen has the same two options above; but when Linux is running as a
>> dom0 under Xen, there are three places to put it:
>> 1. The screen
>> 2. A serial line
>> 3. Send it to Xen to put wherever Xen is putting it
>>
>> #1 is easy, but #2 is tricky because Xen is likely to be already using
>> the serial port you want to use.
>>
>> "console=hvc0" is #3.
>>
>> What's your Xen command-line look like?  The default should be
>> "console=com1,tty", so Xen's output should show up both places (and so
>> should Linux's if it's set to console=hvc0).
>
>
> This is what's defined in /etc/default/grub following the install of the
> Xen:
>
> GRUB_CMDLINE_XEN_DEFAULT="dom0_mem=1024M,max:1024M cpuinfo com1=115200,8n1
> console=com1,tty loglvl=all guest_loglvl=all"
> GRUB_CMDLINE_LINUX_XEN_REPLACE_DEFAULT="console=hvc0 earlyprintk=xen
> nomodeset"
>
> I didn't set these myself, this is what the xen package (or one of its
> dependencies) is doing.

It's the CentOS Xen package setting this.  But the Xen option
"console=com1,tty" should make it such that Xen sends its output
*both* to the serial line, *and* the monitor.

I take it you're not seeing any Xen output at all on your IPMI console?

 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

Re: [CentOS-virt] Clocksource boot issues 4.9.13

[George Dunlap]

On Sun, Apr 2, 2017 at 9:22 PM, Sarah Newman <s...@prgmr.com> wrote:
> On 04/02/2017 02:49 AM, Chris Elliott wrote:
>> Hi all
>>
>> I’ve got a few Intel Z87 chipset machines with Adaptec 5405 raid cards 
>> (latest firmware), they work fine on 3.18 but during Dom0 boot using kernel
>> 4.9.13 it hangs at “Using clocksource tsc” and the aacraid driver keeps 
>> trying to reset
>>
>> Has anyone seen anything like this?
>>
>> I’ve tried specifying clocksource=xen in grub instead of the default of tsc, 
>> and that has the same issue. HPET is enabled and Xen is seeing it:
>>
>> (XEN) ACPI: HPET D9649CB0, 0038 (r1 ALASKAA M I  1072009 AMI.5) 
>> (XEN) Platform timer is 14.318MHz HPET
>
> I saw a hang at a similar place in the boot process when trying to boot 
> xen-on-xen for our test system. On a hunch I was going to to try recompiling
> without the PVHVM PCI related driver (pci-platform ? platform-pci ? ) before 
> saying anything about it.
>
> Since you tried changing the clock source I'm wondering is that the boot 
> issue is unrelated to the clock source, in which case you may get a better
> idea of what's hanging by comparing the boot logs from 3.18 to 4.9 and seeing 
> what's present in 3.18 but not in 4.9. Presumably the messages in the
> 3.18 but not 4.9 logs are either removed from the kernel source or happen 
> after whatever is hanging.

The Xen-on-xen thing is a specific problem with nested Xen; I asked on
xen-devel and was pointed to this commit.

Unfortunately it's pretty unlikely this one will help Chris.

But perhaps, Chris, if you follow my example and post a bug report to
xen-devel (with serial output from Xen and the guest kernel), someone
may be able to find a patch which fixes the problem.

 -George
commit eb857975e4eb182a145764d2d06acff6ef696494
Author: Stefano Stabellini <sstabell...@kernel.org>
Commit: George Dunlap <george.dun...@citrix.com>

partially revert "xen: Remove event channel notification through Xen PCI platform device"

Commit 72a9b186292d ("xen: Remove event channel notification through Xen
PCI platform device") broke Linux when booting as Dom0 on Xen in a
nested Xen environment (Xen installed inside a Xen VM). In this
scenario, Linux is a PV guest, but at the same time it uses the
platform-pci driver to receive notifications from L0 Xen. vector
callbacks are not available because L1 Xen doesn't allow them.

Partially revert the offending commit, by restoring IRQ based
notifications for PV guests only. I restored only the code which is
strictly needed and replaced the xen_have_vector_callback checks within
it with xen_pv_domain() checks.

Signed-off-by: Stefano Stabellini <sstabell...@kernel.org>
Reviewed-by: Boris Ostrovsky <boris.ostrov...@oracle.com>

diff --git a/drivers/xen/platform-pci.c b/drivers/xen/platform-pci.c
index b59c9455..549c618 100644
--- a/drivers/xen/platform-pci.c
+++ b/drivers/xen/platform-pci.c
@@ -42,6 +42,7 @@
 static unsigned long platform_mmio;
 static unsigned long platform_mmio_alloc;
 static unsigned long platform_mmiolen;
+static uint64_t callback_via;
 
 static unsigned long alloc_xen_mmio(unsigned long len)
 {
@@ -54,6 +55,51 @@ static unsigned long alloc_xen_mmio(unsigned long len)
 	return addr;
 }
 
+static uint64_t get_callback_via(struct pci_dev *pdev)
+{
+	u8 pin;
+	int irq;
+
+	irq = pdev->irq;
+	if (irq < 16)
+		return irq; /* ISA IRQ */
+
+	pin = pdev->pin;
+
+	/* We don't know the GSI. Specify the PCI INTx line instead. */
+	return ((uint64_t)0x01 << HVM_CALLBACK_VIA_TYPE_SHIFT) | /* PCI INTx identifier */
+		((uint64_t)pci_domain_nr(pdev->bus) << 32) |
+		((uint64_t)pdev->bus->number << 16) |
+		((uint64_t)(pdev->devfn & 0xff) << 8) |
+		((uint64_t)(pin - 1) & 3);
+}
+
+static irqreturn_t do_hvm_evtchn_intr(int irq, void *dev_id)
+{
+	xen_hvm_evtchn_do_upcall();
+	return IRQ_HANDLED;
+}
+
+static int xen_allocate_irq(struct pci_dev *pdev)
+{
+	return request_irq(pdev->irq, do_hvm_evtchn_intr,
+			IRQF_NOBALANCING | IRQF_TRIGGER_RISING,
+			"xen-platform-pci", pdev);
+}
+
+static int platform_pci_resume(struct pci_dev *pdev)
+{
+	int err;
+	if (!xen_pv_domain())
+		return 0;
+	err = xen_set_callback_via(callback_via);
+	if (err) {
+		dev_err(>dev, "platform_pci_resume failure!\n");
+		return err;
+	}
+	return 0;
+}
+
 static int platform_pci_probe(struct pci_dev *pdev,
 			  const struct pci_device_id *ent)
 {
@@ -92,6 +138,28 @@ static int platform_pci_probe(struct pci_dev *pdev,
 	platform_mmio = mmio_addr;
 	platform_mmiolen = mmio_len;
 
+	/* 
+	 * Xen HVM guests always use the vector callback mechanism.
+	 * L1 Dom0 in a nested Xen environment is a PV guest inside in an
+	 * HVM environment. It ne

Re: [CentOS-virt] Xen C6 kernel 4.9.13 and testing 4.9.15 only reboots.

[George Dunlap]

On Tue, Mar 28, 2017 at 10:55 PM, PJ Welsh  wrote:
> The mystery gets more interesting... I now have a CentOS 7.3 Dell R710
> server doing the exact same thing of rebooting immediately after the Xen
> kernel load. Just to note this is a second system and not just the first
> system with an update. I hope I'm not introducing something odd. They only
> "interesting" thing I have done for historical reasons is to change the
> following /etc/sysconfig/grub line:
> GRUB_CMDLINE_XEN_DEFAULT="dom0_mem=6G,max:8G cpuinfo com1=115200,8n1
> console=com1,tty loglvl=all guest_loglvl=all"
> But I've done that on other servers without issue. In fact I have a Dell
> R710 that DOES work with CentOS 7 and the new kernel... so confused.

PJ,

Thanks for your testing and report.  Would you mind reporting this on
xen-devel?  If there's actually a bug in the Linux  4.9.x on Xen boot
path on your box, I don't think Johnny or I are going to be able to
help you debug it. :-)

 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

Re: [CentOS-virt] Selinux Problem

[George Dunlap]

On Thu, Feb 2, 2017 at 4:46 PM, -=X.L.O.R.D=-  wrote:
> Selinux is way too complicated for Xen environment, there are other 
> alternative to security your system than SeLinux.

But the core repository for SELinux has rules for all the Xen
functionality, which CentOS mostly inherits.  This is primarily, I
think, because Fedora has Xen packages (and also enables SELinux by
default).

 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

Re: [CentOS-virt] Selinux Problem

[George Dunlap]

On Thu, Jan 26, 2017 at 8:08 PM, Günther J. Niederwimmer
 wrote:
> Hello,
>
> Am Donnerstag, 26. Januar 2017, 10:54:20 CET schrieb Johnny Hughes:
>> On 01/26/2017 10:06 AM, Günther J. Niederwimmer wrote:
>> > Hello,
>> >
>> > CentOS 7.(3) Xen 4.4,
>> >
>> > Can I find any Doc for selinux with XEN, I found many Problems with
>> > selinux on Dom0 ?
>> >
>> > Or have I to disable selinux when I install XEN.
>> >
>> > Thank's for a answer.
>>
>> We have not tried to make xen work with selinux on Dom0 .. in fact our
>> documentation:
>>
>> https://wiki.centos.org/Manuals/ReleaseNotes/Xen4-01
>>
>>  says:
>>
>> SELinux support is disabled, and you might need to disable SELinux on
>> the dom0 for some operations; primarily when using qemu-xen and blktap
>> backed storage.
>
> This is not the best Situation, but when I have no other way I have to disable
> selinux :-(.

I think that comment may be a little old.  I do try to support SELinux
-- the smoke tests I use before pushing changes have it enabled by
default, and they use both qemu-xen and blktap.

But it's difficult to help debug problems when you haven't even said
what problem(s) you're having. :-)

Please be sure to include the output of `dmesg`, `xl dmesg`, your
xl.cfg, and /var/log/audit/audit.log.

Thanks,
 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

Re: [CentOS-virt] Updated libvirt packages (2.2.0-1) in testing

[George Dunlap]

On Fri, Jan 6, 2017 at 10:26 AM, Jean-Marc Liger
<jean-marc.li...@parisdescartes.fr> wrote:
> Le 05/01/2017 à 18:29, George Dunlap a écrit :
>>
>> The CentOS 7.3 release updated to libvirt 2.0,  which is now taking
>> precedence over the previous virt sig libvirt packages (which were
>> 1.3).
>>
>> I've pulled in the changes from Fedora 25, which uses libvirt 2.2.0.
>> I've built and tested them for CentOS 7 and they work for me.  (I'm
>> having some infrastructure issue testing C6.)
>>
>> Please test them if you have an opportunity.  I'll leave them there
>> for a week and then push them to release if I don't have any
>> complaints.
>
>
> Hi Georges,
>
> You should pick last libvirt packages directly from
> ftp://ftp.libvirt.org/libvirt/ as they maintain compatibility for both C6
> and C7.

Hmm -- I didn't realize that libvirt shipped their own source rpms.

There seem to be two distinct classes of users: those who want the
newest thing all the time, and those who want to stick with what's
working as long as possible before upgrading.  On the whole, CentOS
seems to be more focused on the second class of people.  So I was
looking to do a single version bump that we could stick with until the
next time there's a compelling reason to update.  Libvirt 2.2 the most
recent one used in any Fedora release.  As such, in terms
of"aftercare" like bug fixes, it will probably get better and for
longer than other releases.  So it seemed like a good option.

I'm open to other suggestions, but "update every release" is probably
not suitable for the main Xen repo.  I wouldn't be opposed if someone
wanted to step up and maintain a repo themselves, though. :-)

 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

Re: [CentOS-virt] Updated libvirt packages (2.2.0-1) in testing

[George Dunlap]

On Thu, Jan 5, 2017 at 6:38 PM, Francis The Metman
 wrote:
> I have tried updating using yum update and get the same error as before:
> ==
> ---> Package libvirt-daemon.x86_64 0:1.3.0-1.el7 will be updated
> --> Processing Dependency: libvirt-daemon = 1.3.0-1.el7 for package:
> libvirt-daemon-driver-libxl-1.3.0-1.el7.x86_64
> --> Processing Dependency: libvirt-daemon = 1.3.0-1.el7 for package:
> libvirt-daemon-driver-xen-1.3.0-1.el7.x86_64
> --> Finished Dependency Resolution
> Error: Package: libvirt-daemon-driver-libxl-1.3.0-1.el7.x86_64
> (@centos-virt-xen)
>Requires: libvirt-daemon = 1.3.0-1.el7
>Removing: libvirt-daemon-1.3.0-1.el7.x86_64 (@centos-virt-xen)
>libvirt-daemon = 1.3.0-1.el7
>Updated By: libvirt-daemon-2.0.0-10.el7_3.2.x86_64 (updates)
>libvirt-daemon = 2.0.0-10.el7_3.2
>Available: libvirt-daemon-1.2.15-104.el7.x86_64 (centos-virt-xen)
>libvirt-daemon = 1.2.15-104.el7
>Available: libvirt-daemon-2.0.0-10.el7.x86_64 (base)
>libvirt-daemon = 2.0.0-10.el7
> Error: Package: libvirt-daemon-driver-xen-1.3.0-1.el7.x86_64
> (@centos-virt-xen)
>Requires: libvirt-daemon = 1.3.0-1.el7
>Removing: libvirt-daemon-1.3.0-1.el7.x86_64 (@centos-virt-xen)
>libvirt-daemon = 1.3.0-1.el7
>Updated By: libvirt-daemon-2.0.0-10.el7_3.2.x86_64 (updates)
>libvirt-daemon = 2.0.0-10.el7_3.2
>Available: libvirt-daemon-1.2.15-104.el7.x86_64 (centos-virt-xen)
>libvirt-daemon = 1.2.15-104.el7
>Available: libvirt-daemon-2.0.0-10.el7.x86_64 (base)
>libvirt-daemon = 2.0.0-10.el7
>  You could try using --skip-broken to work around the problem
>  You could try running: rpm -Va --nofiles --nodigest
> ==
> I have tried the suggestions, but still no go.
> Anyone any ideas?

Did you enable the testing repo?

yum --enablerepo=centos-virt-xen-testing update

 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

[CentOS-virt] Updated libvirt packages (2.2.0-1) in testing

[George Dunlap]

The CentOS 7.3 release updated to libvirt 2.0,  which is now taking
precedence over the previous virt sig libvirt packages (which were
1.3).

I've pulled in the changes from Fedora 25, which uses libvirt 2.2.0.
I've built and tested them for CentOS 7 and they work for me.  (I'm
having some infrastructure issue testing C6.)

Please test them if you have an opportunity.  I'll leave them there
for a week and then push them to release if I don't have any
complaints.

Thanks,
 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

Re: [CentOS-virt] recent Xen XSA's (199-204)

[George Dunlap]

On Thu, Jan 5, 2017 at 4:51 PM, Brandon Shoemaker  wrote:
> Hello again,
>
> I still actually do not see these Xen updates available for Xen 4.6.3-4.el6
> Centos6?  I've checked a few different servers of mine over the last few
> days.

They should at least be available (unsigned) from centos-virt-xen-testing.

KB I guess hasn't been doing any signing runs over the holidays, and
said he'd do his first one today.  I'll ping him to see if the Xen one
managed to get picked up (it sometimes gets missed for some reason).

 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

Re: [CentOS-virt] yum update Failing with libvirt-daemon error

[George Dunlap]

On Sat, Dec 31, 2016 at 10:34 AM, Jean-Marc Liger
 wrote:
> Jiri Denemark has already proposed to help rebuild libvirt for CentOS-Xen
> but I don't know if he got all that is need to do so ?
>
> Maybe I could help also, but I would have to learn the Centos build system
> first.

Jean-Marc has hit the nail on the head: CentOS 7.3 has updated
libvirt, which is now wanting to replace the Virt SIG versions of
libvirt.

Sorry I missed your mail back in November.  I've actually got a branch
you could have sent a pull-request to here:

 https://github.com/CentOS-virt7/xen-libvirt

However, I've got a plan for keeping this in sync with the Fedora
packages that I haven't documented it yet. :-)

So let me do an update, and also write up some documentation, so that
next time you (or someone else) can send pull requests when something
like this happens.

 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

[CentOS-virt] Xen 4.6.3-3: Import XSA-190

[George Dunlap]

Xen 4.6.3-3 packages, with XSA-190, are currently making their way
through the build system.  The vulnerability is an intra-guest
information leak (i.e., between different processes in the same VM).

More information here:

https://xenbits.xen.org/xsa/advisory-190.html

 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

[CentOS-virt] xen 4.6.3-2 packages (with XSAs 185-188) making their way through CBS

[George Dunlap]

Just a heads-up -- 4.6.3-2, for both CentOS 7 and CentOS 6, are making
their way through the build system now and should be in the mirrors
hopefully sometime later this afternoon.

These contain patches for XSAs 185-188, one of which is a fairly
critical update, so please update as soon as they're available.

 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

Re: [CentOS-virt] Downgrading from Xen 4.6 to 4.5

[George Dunlap]

On Mon, Aug 8, 2016 at 9:33 AM, Francis Greaves  wrote:
>
>> > working in 4.6 for some people, but is working in 4.5
>> > How can I downgrade to Xen 4.5 so I can test this out?
>> > Many thanks
>>
>> We do not provide a CentOS-7 version of Xen lower than 4.6.  At the
>> time
>> we started Xen support on CentOS-7, 4.6 was already stable and that
>> was
>> our first release for CentOS-7.
>>
>> We do currently have both Xen-4.4 and Xen-4.6 for CentOS-6.
>>
>> The Virt SIG produces 'even' versions of Xen (so 4.4, 4.6, 4.8) as
>> well
>> as a newer libvirt and kernel.
>
> Thanks, Johnny for the info
> Is it possible to go up to 4.7 or 4.8, if so, how do I do this? I have read 
> that USB Passthrough is probably OK in 4.7

The Virt SIG is only going to have officially-supported releases every
other Xen release.  If you want to build your own unsupported package
based on the CentOS patchqueue I could send you a link to it.
Otherwise you'll have to wait until 4.8 comes out (probably around
December / January).

 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

[CentOS-virt] Updated Xen packages available

[George Dunlap]

Due to the nature of XSA-182, we built binaries privately and pushed
the signed binaries out as soon as the embargo lifted.

Everyone is urged to update as soon as possible.

 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

Re: [CentOS-virt] PCI Passthrough not working

[George Dunlap]

On Sun, Jul 3, 2016 at 12:34 PM, Francis Greaves  wrote:
> 
> From: "Francis Greaves" 
> To: "Francis Greaves" , "centos-virt"
> 
> Sent: Sunday, 3 July, 2016 11:19:49
> Subject: Re: [CentOS-virt] PCI Passthrough not working
>
> Further to my last post, I have removed the xen-pciback module from the Dom0
> kernel, and reloaded it as
> modprobe xen-pciback passthrough=1
>
> I now have the PCI device on the DomU matching the Dom0 Device
> usb usb1: SerialNumber: :00:1a.0
> instead of :00:00.0
>
> However I now have this error
>
> ehci_hcd :00:1a.0: Unlink after no-IRQ?  Controller is probably using
> the wrong IRQ.
>
> does this give a clue as to what is going on?

Francis,

Thanks for posting with the extra info.  Could you now also re-post it
to the xen-users mailing list, as I asked, so that more people can get
a look at what you're doing?

Thanks. :-)

 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

Re: [CentOS-virt] PCI Passthrough not working

[George Dunlap]

On Wed, Jun 22, 2016 at 10:56 AM, Francis Greaves  wrote:
> Further to my messages back in May I have at last got round to trying to
> get my DomU to recognise USB devices.
>
> I am using Xen 4.6 with CentOS kernel 3.18.34-20.el7.x86_64.
> I have to manually make the port available before creating the DomU by
> issuing the command:
> xl pci-assignable-add 00:1a.0
> otherwise nothing shows in:
> xl pci-assignable-list
>
> I have added this to my .cfg file as per the May Emails:
> pci=['00:1a.0,rdm_policy=relaxed']

The two-stage process for assigning pci devices (first
pci-assignible-add, then pci-add) is a "seatbelt" to make sure that an
accidental mis-type doesn't cause you to grab (say) your hard disk
controller instead of your USB controller.

You can add "seize=1" to your pci string to have xl automatically do
both steps for you.  Obviously, use this with care. :-)

More on your next post...

 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

Re: [CentOS-virt] [CentOS-devel] docker and docker-latest packages on CentOS Virt SIG

[George Dunlap]

On Mon, Jun 13, 2016 at 12:23 PM, Nico Kadel-Garcia <nka...@gmail.com> wrote:
> On Mon, Jun 13, 2016 at 6:39 AM, George Dunlap <dunl...@umich.edu> wrote:
>> On Fri, Jun 10, 2016 at 9:11 PM, Lokesh Mandvekar
>> <l...@fedoraproject.org> wrote:
>>> Moving this discussion to centos-virt@ as it's upto the SIG to decide on
>>> how this moves ahead.
>>>
>>> I'm hoping to have 2 new koji tag sets:
>>>
>>> virt7-docker-fedora-* (will have fedora rpms rebuilt)
>>> virt7-docker-el-* (will have rhel candidate builds before they are released
>>> or land in centos extras)
>>>
>>> The -el-* repos will help to have Virt SIG as sort of an upstream and early 
>>> QA
>>> for both RHEL and CentOS extras.
>>>
>>> If the SIG is ok with it, I'll check with CBS guys to create these 2 tags.
>>>
>>> See below message to centos-devel@ and
>>> http://centos-devel.1051824.n5.nabble.com/CentOS-devel-docker-and-docker-latest-packages-on-CentOS-Virt-SIG-td5712734.html
>>> for background
>>
>> I think having the RHEL version makes sense; but I'm not sure exactly
>> what we gain from having a version labelled "fedora".  If someone
>> wanted the Fedora docker, why wouldn't they just install Fedora?  And
>> if in this case "Fedora" really just stands for "Recently stable
>> docker", then we should probably just come up with another name for it
>> that describes it better (even if in the end it turns out to be a
>> straight re-building of the Fedora RPM).
>
> I pesonally do this kind of backporting, a *lot* with Perl and Python
> modules. They're often sadly out of date on a RHEL production grade
> system, but switching to a Fedora base for your production
> environments can get really flakey, really fast due to the immense
> churn of that operating system.

Right, so one of the basic nice things about the CentOS SIGs is that
all the stuff you don't need to be current can be RHEL-stable, and the
handful of things you do want to be current can be fresh.

My main question is whether explicitly calling it "Fedora" is the
right thing to do (even if in practice it's just a re-build of the
Fedora package).

 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

Re: [CentOS-virt] [CentOS-devel] docker and docker-latest packages on CentOS Virt SIG

[George Dunlap]

On Fri, Jun 10, 2016 at 9:11 PM, Lokesh Mandvekar
 wrote:
> Moving this discussion to centos-virt@ as it's upto the SIG to decide on
> how this moves ahead.
>
> I'm hoping to have 2 new koji tag sets:
>
> virt7-docker-fedora-* (will have fedora rpms rebuilt)
> virt7-docker-el-* (will have rhel candidate builds before they are released
> or land in centos extras)
>
> The -el-* repos will help to have Virt SIG as sort of an upstream and early QA
> for both RHEL and CentOS extras.
>
> If the SIG is ok with it, I'll check with CBS guys to create these 2 tags.
>
> See below message to centos-devel@ and
> http://centos-devel.1051824.n5.nabble.com/CentOS-devel-docker-and-docker-latest-packages-on-CentOS-Virt-SIG-td5712734.html
> for background

I think having the RHEL version makes sense; but I'm not sure exactly
what we gain from having a version labelled "fedora".  If someone
wanted the Fedora docker, why wouldn't they just install Fedora?  And
if in this case "Fedora" really just stands for "Recently stable
docker", then we should probably just come up with another name for it
that describes it better (even if in the end it turns out to be a
straight re-building of the Fedora RPM).

 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

[CentOS-virt] Xen 4.7rc4 packages available for testing

[George Dunlap]

As per our policy, the next officially supported Virt SIG Xen version
will be 4.8.  However, with 4.7 coming soon, I've ported the
patchqueue over to 4.7rc4 and given it a spin.  If you want to help
testing for the upstream 4.7 release, do give it a spin and report any
regressions.

Please note that this version WILL NOT SUPPORTED.  4.6 is still the
officially-supported version until 4.8 comes out (probably in around 6
month's time).

Thanks,
 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

Re: [CentOS-virt] Xen4CentOS 6 64bit - domUs don't shutdown on dom0 after "yum upgrade" to 4.6.1

[George Dunlap]

On Tue, May 24, 2016 at 10:20 PM, exvito here <ex.vitor...@gmail.com> wrote:
> On Tue, May 24, 2016 at 3:23 PM, George Dunlap <dunl...@umich.edu> wrote:
>>
>> The patches have been backported and are available in 4.6.1-9 from
>> virt-xen-testing.  Please test it and report any problems here.
>>
>
> Thanks for the notice. It doesn't look like the fix went in. See below:
>
> # yum repolist | grep xen
> centos-virt-xen-testing  CentOS-6 - xen - testing
> 102
> # rpm -qf /etc/xen/scripts/hotplugpath.sh
> xen-runtime-4.6.1-9.el6.x86_64
> # rpm -V xen-runtime
>
> Confirmed installation of 4.6.1-9 from virt-xen-testing. Confirmed
> files "as packaged".
>
> # grep LOCK /etc/xen/scripts/hotplugpath.sh
> XEN_LOCK_DIR="/var/lock"
>
> The XEN_LOCK_DIR still points to the wrong directory.
> Am I missing something?

Yes, you are missing someting. :-)  XEN_LOCK_DIR is used for a number
of different things; but *only* "I am alive" init script files should
live in /var/lock/subsys.  (Presumably that's why it's a separate
directory to begin with.)  So the "proper" fix is to have the
xendomains script check for the existence of $XEN_LOCK_DIR/subsys and
use it if available.  See my original patch submission for more
details [1].

So, I've tested the packages and they work for me, let me know if you
have any problems. :-)

 -George

[1] http://www.gossamer-threads.com/lists/xen/devel/431063
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

[CentOS-virt] XSA-176 (xen-4.6.1-8) in centos-virt-testing

[George Dunlap]

Builds for Xen 4.6 with XSA-176 backported are available in
centos-virt-testing.  Please test them and report any problems here;
signed builds should be available tomorrow morning.

 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

Re: [CentOS-virt] PCI Passthrough not working

[George Dunlap]

On Mon, May 16, 2016 at 2:14 PM, Francis Greaves  wrote:
>>On Mon, May 16, 2016 at 12:00 PM, Francis Greaves  wrote:
>>> Dear George please find attached the three files as requested.
>>> I have used
>>>
>>> iommu=soft
>>>
>>> in the grub command line for the kernel in the domU as explained before.
>>> many thanks
>
>>The options are:
>>1. Figure out what the other device is and assign them both to the guest
>>2. Tell Xen that you don't mind the sharing.
>>
>>You should only do #2 if you're not using Xen for isolation -- i.e.,
>>if you trust the software in that VM not to attack dom0.
>>
>>I *think* you should be able to do #2 by adding 'rdm_policy=relaxed'
>>to your pci stanza; i.e., it should look like this:
>>
>>pci=['00:1a.0,rdm_policy=relaxed']
>
> Dear George
> That worked, do I still need to add this to the cfg file?
>
> usb=1
> usbdevice=['host:0529:0514']
>
> or how do I assign the device without the 'rdm_policy=relaxed' option as per 
> option 1?

Sorry, I don't understand your question.

In the pci case, you're passing through an entire USB controller.  The
guest will get access to anything plugged into that controller as
though it were running on native.

In the second case, you're presenting an emulated controller, and then
having qemu pass commands through to the device.  This should also
work, but may be a bit slower.

But for 4.6 it's only available in HVM mode -- and the config file you
attached was set up to run in PV mode (if I remember correctly).

> Thanks so much for your speedy advice.

Responding right away means I can delete it and forget about it. ;-)

 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

Re: [CentOS-virt] Xen 4.6 initscripts locking problem

[George Dunlap]

On Mon, May 16, 2016 at 12:34 PM, Piotr Gackiewicz
 wrote:
>
> Hello,
>
> According to Xen4Centos wiki, Xen bugs should be reported by
> bugs.centos.org, Centos-6 => Xen4 project.
>
> I have reported a bug with initscripts locking in xen-runtime-4.6-6
> https://bugs.centos.org/view.php?id=10807
>
> Meanwhile, new xen-runtime-4.6-7 has been issued (in testing repo), and this
> bug is still present.
>
> Does anybody handle these bugs in bugs.centos.org, or should I report it
> elsewhere?  :-)

My patches for this issue were just accepted upstream last week, I
just haven't had a chance to push them into the Virt SIG repos yet.

FWIW the goal of the XSA-related updates is to minimize the amount of
changes, so that people can have confidence that there's a minimal
risk of breaking on upgrade.  That's why random other fixes aren't
generally included in those updates.

 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

Re: [CentOS-virt] [x-post] Upstream possible patches to libvirt to enable building upstream libvirt packages with libxl

[George Dunlap]

Le,

It's not clear to me what you want.  Are you asking the Virt SIG to
update to a newer version of libvirt?

 -George

On Sun, May 15, 2016 at 7:42 PM, Le Nucksi  wrote:
> On 05/14/2016 07:16 AM, Le Nucksi wrote:
>> Hello list,
>>
>> is there a way to get more recent libvirt builds for CentOS 7 that include
>> support for the xl (modern Xen) toolstack?
>>
>> I tried to build libvirt from the SRPM, which succeeded, however, without
>> the mentioned Xen parts.
>> I have also found two repos from people who provide upstream libvirt builds
>> for CentOS 7, again, without the Xen parts.
>> - https://copr.fedorainfracloud.org/coprs/jmliger/virt7-upstream/ and
>> - https://build.opensuse.org/package/show/home:aevseev/libvirt
>>
>> Within the CentOS virtualization SIG builds for Xen there is a 1.3.x build
>> of libvirt that includes support for the modern Xen toolstack.
>> Would it be possible to inline this into the upstream to enable building it
>> with Xen features on CentOS 7 such that the aforementioned people's RPMs
>> would contain it?
>>
>> I appreciate any enlightment on the topic.
>
> I think you should either contact the owners of those libvirt repos, or
> contact the centos virt sig. I don't know if anyone on these lists is directly
> involved with those repos
>
> - Cole
>
> Hello list,
>
> I emailed the libvirt-users list to see if there would be a way to get more
> recent libvirt builds into my CentOS 7 + VIRT SIG/Xen packages.
>
> Here's what Cole Robinson from RedHat replied on that matter. Also the
> initial email.
>
> I'd appreciate your feedback on this. The more recent libvirt builds appear
> to include quite some improvements especially for the libxl parts.
>
> Best regards,
> Le
>
> ___
> CentOS-virt mailing list
> CentOS-virt@centos.org
> https://lists.centos.org/mailman/listinfo/centos-virt
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

Re: [CentOS-virt] PCI Passthrough not working

[George Dunlap]

On Thu, May 12, 2016 at 12:11 PM, Francis Greaves  wrote:
> I am running Xen 4.6 on CentOS 7 in a Dell Poweredge T430
> I need PCI Passthrough to get USB working. I am following the Xenproject
> Wiki
> I have enabled the Virtulasation in the BIOS.
> I have xen_pciback as a module
> I have issued the command:
>
> xl pci-assignable-add 00:1a0.0 and it shows up fine when I issue this xl
> pci-assignable-list
>
> I have pci=['00:1a.0'] on the DomU config file
> I have added this iommu=soft and swiotlb=force both together and separately
> to the kernel command line
> in the DomU (running Debian 8), but I get the same error each time.
>
> libxl: error: libxl_pci.c:999:do_pci_add: xc_assign_device failed: Operation
> not permitted
> libxl: error: libxl_create.c:1424:domcreate_attach_pci: libxl_device_pci_add
> failed: -3

Can you please attach the following:
1. The complete domU config file
2. A complete log of the command and all the output
3. The full output of "xl dmesg" just after you run the command

Thanks,
 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

Re: [CentOS-virt] migrating from xend to libxl after xen 4.6.1

[George Dunlap]

On Sat, Apr 16, 2016 at 5:40 PM, rgritzo  wrote:
> so i guess i was not paying too close attention and upgraded to xen 4.6.1 
> before i migrated my domU configurations to libxl :{

Just FYI, as a fall-back you can always move yourself to the Xen 4.4 "track" by:
1. Installing centos-release-xen-44
2. Removing centos-release-xen
3. "yum downgrade" all the Xen packages.

This will switch you to repos which will only have Xen 4.4; and Johnny
will be doing XSA backports until the 4.4 EOL in 2017.  You can
upgrade to 4.6 again by either re-installing centos-release-xen (which
will update to the latest automatically) or installing
centos-release-xen-46 (which will stay on Xen 4.6).  (You can install
multiple packages at the same time; yum will just choose the highest
version available.)

> i have tried for a couple of hours this morning to find a way to do the 
> conversion in a post xend world, but can’t seem to do it.
> I still have all my disk images, and i see the domain config.sxp 
> configuration files in /var/lib/xend/domains/ but i am not enough of a 
> xen expert to figure out how to migrate those.
>
> is there a simple way to move to libxl now that xend is gone and i did not 
> dump the xml files?

So just checking -- the issue here is that you're not using the
".cfg"-style config files, but the sxp-style config files?  You're not
using libvirt, is that right?

Unfortunately parsing sxp config files and running "managed domains"
are one feature that was explicitly chose as something we wouldn't be
supporting in xl going forward [1].  You'll probably have to do some
sort of manual conversion.

 -George

[1] http://wiki.xen.org/wiki/XL#Anti-Features
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

[CentOS-virt] Reminder: Virt SIG meeting at 3pm BST (2pm UTC) today on #centos-devel

[George Dunlap]

Reminder that (at least for the moment), unlike many of the other
meetings, our meeting is on British time at 3pm.

 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

[CentOS-virt] XSA-172

[George Dunlap]

xen 4.6.1-5 has been build and should be available in buildlogs soon
(available via the centos-virt-xen-testing repo).

More information can be found here:

http://xenbits.xen.org/xsa/advisory-172.html

A signed copy should hit the mirrors tomorrow.

Please report any problems on this list.

Thanks,
 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

[CentOS-virt] ANNOUNCEMENT: centos-release-xen switching to 4.6 later this week

[George Dunlap]

In preparation for XSA-172, due to be made public next week (29
March), as discussed previously, I'm going to be updating the
centos-release-xen package to point to Xen 4.6 rather than 4.4.

As a reminder, you can "pin" your installation to Xen 4.4 by
installing centos-release-xen-44 and then removing centos-release-xen.

Also, I will not be applying any more patches to the Xen 4.4 packages.
I will, however, review and push through the build system pull
requests sent to https://github.com/CentOS-virt7/xen.

 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

Re: [CentOS-virt] Soft lockups with Xen4CentOS 3.18.25-18.el6.x86_64

[George Dunlap]

On Sat, Mar 12, 2016 at 11:47 PM, Sarah Newman  wrote:
> On 03/10/2016 12:05 AM, Sarah Newman wrote:
>> On 03/09/2016 08:15 PM, Sarah Newman wrote:
>>> I've been running 3.18.25-18.el6.x86_64 + our build of xen 4.4.3-9 on one 
>>> host for the last couple of weeks and have gotten several soft lockups
>>> within the last 24 hours. I am posting here first in case anyone else has 
>>> experienced the same issue.
>>>
>>
>> Here is mpstat from around the time of the issue:
>>
>> 0:08:56 PM  CPU%usr   %nice%sys %iowait%irq   %soft  %steal  
>> %guest   %idle
>> 10:09:10 PM  all0.000.00   66.670.000.00   33.330.00
>> 0.000.00
>> 10:09:11 PM  all2.170.005.43   32.610.00   58.701.09
>> 0.000.00
>> 10:09:12 PM  all0.000.001.150.000.00   85.060.00
>> 0.00   13.79
>> 10:09:13 PM  all0.000.001.080.000.00   83.870.00
>> 0.00   15.05
>> 10:09:14 PM  all0.000.001.100.000.00   83.520.00
>> 0.00   15.38
>> 10:09:15 PM  all1.090.001.090.000.00   85.870.00
>> 0.00   11.96
>> 10:09:51 PM  all0.000.001.090.000.00   84.781.09
>> 0.00   13.04
>> Message from syslogd at Mar  9 22:09:51 ...
>>  kernel:NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [swapper/0:0]
>> 10:10:02 PM  all0.000.00   33.33   50.000.00   16.670.00
>> 0.000.00
>> 10:10:03 PM  all3.160.00   10.538.420.002.111.05
>> 0.00   74.74
>> 10:10:04 PM  all0.000.003.23   38.710.001.081.08
>> 0.00   55.91
>> 10:10:05 PM  all0.000.004.30   11.830.003.231.08
>> 0.00   79.57
>>
>> Typical load:
>>
>> 10:22:15 PM  CPU%usr   %nice%sys %iowait%irq   %soft  %steal  
>> %guest   %idle
>> 10:22:16 PM  all0.000.001.020.000.001.020.00
>> 0.00   97.96
>> 10:22:17 PM  all0.000.000.000.000.000.001.04
>> 0.00   98.96
>> 10:22:18 PM  all0.000.000.000.000.001.011.01
>> 0.00   97.98
>> 10:22:19 PM  all0.000.001.010.000.001.010.00
>> 0.00   97.98
>> 10:22:20 PM  all0.000.000.000.000.000.001.02
>> 0.00   98.98
>> 10:22:21 PM  all0.000.001.020.000.001.020.00
>> 0.00   97.96
>> 10:22:22 PM  all0.000.000.000.000.001.011.01
>> 0.00   97.98
>>
>>
>> I reverted to an older kernel since the older kernel had run for a couple of 
>> months without issues.
>
>
> This did not fix it. I isolated the issue to a vif rate limit of 100Mb/s 
> being applied to one of the guests and am now able to reproduce on a
> different machine.
>
> I will look into whether this has been fixed already; if so I will submit a 
> pull request for the Xen4CentOS kernel and if not I will take it up with
> the xen-devel list.

Yes, I was going to suggest posting this to xen-users -- it's not
unlikely someone has already run across this.

 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

Re: [CentOS-virt] installing xen on c7

[George Dunlap]

On Sat, Feb 27, 2016 at 12:52 PM, Yamaban  wrote:
> On Sat, 27 Feb 2016 13:20, Scot P. Floess wrote:
>> On Sat, 27 Feb 2016, Karanbir Singh wrote:
>>>  On 27/02/16 01:41, Scot P. Floess wrote:
>>> > >  From George's original email, I had to:
>>> > >* Install centos-release-xen from centos-extras
>>> > >  Then a yum update followed by a yum install xen.
>>> > >  That worked for me...
>>> >
>>>  i had to do something similar, but my question is - one cant run xen
>>>  without the kernel, so why not have the xen package require the xen
>>>  kernel as a prereq ?

I mostly took the packages as I got them; and for C6, "yum install
xen" always just grabbed the newer kernel automatically; but this was
apparently because of the version, not because of any advertised
capability it provided.

> IMHO, the best way to solve this would a additional line in the spec-file:
> "Provide: kernel-dom0" for those kernel that are provide this functionality.
>
> Then the xen-packages could "Require: kernel-dom0"
> no matter which way the kernel functionality came to be.

This seems like a good idea.  If anyone wants to send pull requests to
https://github.com/CentOS-virt7/xen and
https://github.com/CentOS-virt7/xen-kernel implementing the change
I'll be happy to merge them.  Otherwise I'll put it on my to-do list.

> Maybe ask even across distros for such a implemention,
> to get a more coherent experience for xen.

I just looked at the Fedora xen package, and it doesn't seem to have
any requirement of that sort.  I think most distro kernels just have
Xen enabled by default, because it's a lot harder to support two
packages than just have it enabled all the time.  RH is the odd one
out to have it disabled entirely.

 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

Re: [CentOS-virt] XSAs 170 and 154, repository layouts, and centos-release-xen 8-1

[George Dunlap]

On Wed, Feb 24, 2016 at 12:01 AM, Karanbir Singh <mail-li...@karan.org> wrote:
> On 23/02/16 15:04, George Dunlap wrote:
>> On Sat, Feb 20, 2016 at 9:24 PM, Sarah Newman <s...@prgmr.com> wrote:
>>> On 02/17/2016 04:30 AM, George Dunlap wrote:
>>>> I have the following packages going through the CBS:
>>>> * A CentOS 7 xen-4.6.1-2, with XSAs 170 and 154
>>>> * A CentOS 6 xen-4.6.1-2, with XSAs 170 and 154
>>>> * A CentOS 6 xen-4.4.3-11, with XSAs 170
>>>>
>>>> All these should show up in mirrors hopefully sometime later today.
>>>> As usual, please report any problems here.
>>>
>>> Domains using the distribution provided pvgrub won't boot after upgrade.
>>>
>>> Old location of pvgrub:
>>>
>>> /usr/lib/xen/boot/pv-grub-x86_32.gz
>>> /usr/lib/xen/boot/pv-grub-x86_64.gz
>>>
>>> New location of pvgrub:
>>>
>>> /usr/lib64/xen/boot/pv-grub-x86_32.gz
>>> /usr/lib64/xen/boot/pv-grub-x86_64.gz
>>
>> FYI I've got a new version that provides symbolic links for backwards
>> compatibility which should have hit buildlogs (aka
>> centos-virt-xen-testing) two hours ago, but hasn't for some reason...
>
>
> can you check and let me know - I've looked at the pending queues a few
> minutes back and found nothing there. So anything due to buildlogs or
> cdn should be pushed already

Yes, it seems to be there now, thanks.

 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

Re: [CentOS-virt] XSAs 170 and 154, repository layouts, and centos-release-xen 8-1

[George Dunlap]

On Sat, Feb 20, 2016 at 9:24 PM, Sarah Newman <s...@prgmr.com> wrote:
> On 02/17/2016 04:30 AM, George Dunlap wrote:
>> I have the following packages going through the CBS:
>> * A CentOS 7 xen-4.6.1-2, with XSAs 170 and 154
>> * A CentOS 6 xen-4.6.1-2, with XSAs 170 and 154
>> * A CentOS 6 xen-4.4.3-11, with XSAs 170
>>
>> All these should show up in mirrors hopefully sometime later today.
>> As usual, please report any problems here.
>
> Domains using the distribution provided pvgrub won't boot after upgrade.
>
> Old location of pvgrub:
>
> /usr/lib/xen/boot/pv-grub-x86_32.gz
> /usr/lib/xen/boot/pv-grub-x86_64.gz
>
> New location of pvgrub:
>
> /usr/lib64/xen/boot/pv-grub-x86_32.gz
> /usr/lib64/xen/boot/pv-grub-x86_64.gz

FYI I've got a new version that provides symbolic links for backwards
compatibility which should have hit buildlogs (aka
centos-virt-xen-testing) two hours ago, but hasn't for some reason...

 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

Re: [CentOS-virt] Kernel 3.18.21-17 and 3.18.21-18 kernel panics

[George Dunlap]

On Mon, Feb 22, 2016 at 6:35 AM, Sarah Newman  wrote:
> On 02/21/2016 08:02 PM, Shaun Reitan wrote:
>> I've seen this issue on about 15 different servers now. Anybody else seeing 
>> this?
>>
>> Screenshot: http://imgur.com/cBcwr8l
>>
>> I also have a video of the boot process if that will be helpful.
>
> Are you missing the initrd line in /boot/grub/menu.lst? That's a known bug 
> that I believe has been fixed with 3.18.25-something.

"Can't find rootfs" is most likely the missing initrd bug, which is
fixed in centos-release-xen-7-12 or later.

You can:

1. Manually add the initrd line to the xen stanza in /boot/grub/menu.lst, or

2. Upgrade to centos-release-xen-7-12 or later, and then

 2a. Run grub-bootxen.sh manually, or

 2b. Update the kernel (which will cause grub-bootxen.sh to be run
automatically).

Peace,
 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

Re: [CentOS-virt] XSAs 170 and 154, repository layouts, and centos-release-xen 8-1

[George Dunlap]

On Thu, Feb 18, 2016 at 1:57 PM, Johnny Hughes <joh...@centos.org> wrote:
> On 02/17/2016 06:30 AM, George Dunlap wrote:
>
> 
>
> For C6 users:
>
>> * If you want to update to xen-46, and also get further updates 
>> automatically:
>>
>> yum install centos-release-xen-46
>
> Would this be instead (to get latest and always stay one latest):
>
> yum remove centos-release-xen44 centos-release-xen46
> yum install centos-release-xen
>
> (instead of installing centos-release-xen46)

Long-term, yes. :-)  But for the time being, centos-release-xen still
points to 4.4, so if you want 4.6, you have to install the 46 package.

The idea is to give people currently on 4.4, who may want to *stay* on
4.4, a window to notice (and test) the new centos-release-xen-44
package before having centos-release-xen automatically update.

 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

Re: [CentOS-virt] XSAs 170 and 154, repository layouts, and centos-release-xen 8-1

[George Dunlap]

On Wed, Feb 17, 2016 at 12:30 PM, George Dunlap <dunl...@umich.edu> wrote:
> I have the following packages going through the CBS:
> * A CentOS 7 xen-4.6.1-2, with XSAs 170 and 154
> * A CentOS 6 xen-4.6.1-2, with XSAs 170 and 154
> * A CentOS 6 xen-4.4.3-11, with XSAs 170
>
> All these should show up in mirrors hopefully sometime later today.
> As usual, please report any problems here.
>
> Xen 4.4 only has XSA 170 because at the time the embargo was lifted, I
> didn't have a suitable backport of XSA-154.  It's only applicable when
> PCI-passthrough is in effect, so it's not that critical.

I now have a build of Xen 4.4 with XSA-154 going through the build
system.  For users who need it, it should be available on buildlogs
(via centos-virt-xen-testing) sometime later this afternoon.  The
signed version on mirrors may be delayed until tomorrow.

And that really will be the last Xen 4.4 XSA update I personally port. :-)

However, if anyone wants to push any further changes to 4.4, feel free
to send a pull request to this tree:

https://github.com/CentOS-virt7/xen

And I'll be happy to review it and push it through the CBS.  I've made
a detailed how-to, so hopefully it shouldn't be too difficult.

Peace,
 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

[CentOS-virt] XSAs 170 and 154, repository layouts, and centos-release-xen 8-1

[George Dunlap]

I have the following packages going through the CBS:
* A CentOS 7 xen-4.6.1-2, with XSAs 170 and 154
* A CentOS 6 xen-4.6.1-2, with XSAs 170 and 154
* A CentOS 6 xen-4.4.3-11, with XSAs 170

All these should show up in mirrors hopefully sometime later today.
As usual, please report any problems here.

Xen 4.4 only has XSA 170 because at the time the embargo was lifted, I
didn't have a suitable backport of XSA-154.  It's only applicable when
PCI-passthrough is in effect, so it's not that critical.

Additionally, we've moved to the new repository layout.  Repositories
will now be tagged with the release; so C6 will have xen-44 and
xen-46, and C7 will have xen-46.  For now, the existing xen/
repository will be a symlink -- to xen-44 for C6 and to xen-46 for C7.

There will be new centos-release-xen packages coming down the line.
As described elsewhere:

* centos-release-xen-44 will always point to the xen-44 repository
* centos-release-xen-46 will always point to the xen-46 repository
* centos-release-xen will (normally) point to whatever the most recent
release is.

For the time being, the C6 version of centos-release-xen will remain
pointing to xen-44.

These packages can be installed at the same time; yum will choose the
most recent release of all available.

= What you need to do (C6 users only) =

* If you want to stay on xen-44:

yum install centos-release-xen-44
yum remove centos-release-xen

* If you want to update to xen-46 and stay there until you choose to update:

yum install centos-release-xen-46
yum remove centos-release-xen

* If you want to update to xen-46, and also get further updates automatically:

yum install centos-release-xen-46

= What you need to do (C7 users) =

Much less urgent, since we don't plan to upgrade until 4.8, but:

* If you want to stay on 46 until you choose to update:

yum install centos-release-xen-46
yum remove centos-release-xen

* If you want to get further updates automatically:

Do nothing, you're already set.
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

[CentOS-virt] Proposal: Version-specific centos-release-xen-NN packages

[George Dunlap]

Thank you for those who raised the issue of upgrading across
potentially disruptive major versions (like the Xen 4.4 -> 4.6
update), and for everyone who weighed in.

After discussing options with users here on this list (as well as in
the IRC channel), further discussing things in the Virt SIG IRC
meeting, and also raising the issue with other SIGs on the
centos-devel list, here are my thoughts.  (Skip down to the "Proposal"
sections for the TLDR version.)

= The issue =

To summarize the issue:

* Some users want to get whatever the latest supported version of Xen
automatically via yum, without having to do anything but a "yum
update".  They want "yum update" to give them a new major version when
one is available.  We can call this group "auto-upgrade", because they
expect a major version upgrade to happen automatically.

* Other users want "yum update" to have fairly strong guarantees not
to break their systems -- and thus want "yum update" *not* to give
them a new major version, but want to have to manually do something
specific (such as installing a different package) to get the updated
version.  Or at very least, they expect not to get a new major version
that is expected to break things.  We can call this group
"manual-upgrade", because they want to manually upgrade major
versions.

* At the moment, the Virt SIG is only committed to making security
updates to one version of Xen at a time

* The 4.4 -> 4.6 update may be particularly disruptive for some users,
since xend/xm will no longer be available.

* Many users may not follow this mailing list, so may not know about
the impending update

* There are new XSAs coming out in 2 days (17 February).

There are basically two "problems" to solve.

The first thing to look at is what we would like things to look
long-term, given that some users want auto-upgrade and some users want
manual-upgrade.

The second thing to look at is what to do in the current situation,
given that we have users from both camps with the same set of packages
installed, who may not read this mailing list.

A couple of goals (some of which are on conflict):

* We'd like to support both types of users

* We want to minimize breakage for people who do don't follow this
list, and do "yum update" without noticing the major upgrade that gets
pushed out.

* We want to minimize the security exposure for people who don't
follow this list, and who don't notice that there haven't been any
updates in response to XSAs.

Additionally, we'd like if possible to be able to make it possible for
anyone who wants to maintain older versions of Xen to do so in
parallel with the newer versions.

= Proposal: Long term =

Going forward, this is what I propose we aim for:

* Have separate repos for each version of Xen; at the present, this
means xen-44 and xen-46.

* Have version-specific centos-release-xen-NN pakcages which will
always point to that version of the repo.  So centos-release-xen-44
will point to xen-44, centos-release-xen-46 will point to xen-46.
Users in the "manual-upgrade" camp can install one of these versions,
knowing that a simple "yum update" will never move them across
versions.  When they're ready to upgrade, they can just install the
newer version; yum will choose the newest version from all the repos
available to it.

* Have a generic centos-release-xen package which will always point to
the most recent 'released' Virt SIG version of Xen.  Users in the
"auto-upgrade" camp can install this version, knowing that they'll
always get the version with the latest security fixes.

This will also make it simple for community members to step up and
support older versions if they desire.

= Discussion: Short term =

For those who do not follow the list, we have to essentially choose
one update policy for them.  Will the current users expecting
"manual-upgrade" have "auto-upgrade" imposed on them (potentially
breaking on update)?  Or will the current users expecting
"auto-upgrade" have "manual-upgrade" imposed on them (potentially
missing important security updates)?

For someone to be negatively affected by the "manual-upgrade" choice,
they only have to be running Xen in any configuration.

For someone to be negatively affected by the "auto-upgrade" choice, they have to
* still be running xend (in spite of having a warning printed on every
xm command invocation for the last 18 months)
* update their systems without checking / noticing the new major version

Even then, they should have the option of downgrading with "yum
downgrade"; there should only be major carnage if they automatically
update large numbers of servers at once.

When I brought this question up with the other SIGs, the general
sentiment was that, as community-run projects, we do not have nearly
the testing effort required to make it possible for users to simply
run "yum update" without checking first.

So on the whole, I think the aggregate risk is minimized if we go with
the "auto-upgrade" option for those who don't 

[CentOS-virt] xen-4.6.1-1 packages for C6 and C6 in centos-virt-xen-testing

[George Dunlap]

Xen 4.6.1 packages are available in centos-virt-xen-testing; please
test, I'll probably be pushing it to the mirrors sometime early next
week (before the upcoming XSAs are due to go public).

To use (assuming you've installed already):

  yum --enablerepo=centos-virt-xen-testing update

Please report any bugs here.

 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

Re: [CentOS-virt] c7 xen-4.6 crash.

[George Dunlap]

On Thu, Feb 4, 2016 at 5:03 PM, President  wrote:
> I wrote about this a couple months back.  George asked me to submit to the
> Xen developers list, but I never had the time due to work demands on getting
> the new server set up.  In my case, I had to use a different server.  The
> new motherboard/CPU had no issues with the second CPU.  If you turn off and
> unplug the second CPU, it will work.

This is a bug that was fixed on the development branch in December; a
fix is included in the recently-released 4.6.1.  I'm testing 4.6.1
packages now, they'll probably hit mirrors in a day or two.

 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

Re: [CentOS-virt] CentOS 6 Virt SIG Xen 4.6 packages available in centos-virt-xen-testing

[George Dunlap]

On Thu, Jan 21, 2016 at 7:17 PM, Sarah Newman <s...@prgmr.com> wrote:
> On 01/21/2016 04:32 AM, George Dunlap wrote:
>
>> I'm a developer, not a server admin, so I can't gauge how important
>> this issue is.  Before making such a change, I'd like to hear opinions
>> from other people in the community about how important (or not) it is
>> to avoid breaking xm, given the ample warning (>1 year) users have
>> had.
>>
>> On the other hand, explicitly moving to a "xen${VER}" (both for C6 and
>> C7) would make it simpler for people to step up and maintain older
>> versions in parallel if anybody wanted to do so.
>
> My inclination is towards a naming scheme like xen46, xen48, etc + a meta 
> package that always depends on the latest. It should be more obvious when
> there's a major upgrade, and those who can't afford a major upgrade can 
> uninstall the meta package.

BTW, we had a discussion about this particular idea at the Virt SIG
meeting, and KB said that different naming of packages like this can
cause dependency problems.  For example, a package depends on
"xen-version >= $N" will fail because as far as rpm is concerned, you
don't have package 'xen' installed at all.

Another idea is to keep separate repos, and then have
"centos-release-xen-$VERSION", which would always point to $VERSION,
and "centos-release-xen", which would always be the newest version.
That might satisfy both types of people.

 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

Re: [CentOS-virt] CentOS 6 Virt SIG Xen 4.6 packages available in centos-virt-xen-testing

[George Dunlap]

On Tue, Feb 2, 2016 at 2:47 PM, Manuel Wolfshant
<wo...@nobugconsulting.ro> wrote:
> On 01/14/2016 06:57 PM, George Dunlap wrote:
>>
>> As mentioned yesterday, Xen 4.6 packages are now available for
>> testing.  These also include an update to libvirt 1.3.0, in line with
>> what's available for CentOS 7.  Please test, particularly the upgrade
>> if you can, and report any problems here.
>>
>> To upgrade:
>>
>> yum update --enablerepo=centos-virt-xen-testing
>>
>> To install from scratch:
>>
>> * Install centos-release-xen from centos-extras
>>
>> yum install centos-release-xen
>>
>> * Update to get the new kernel:
>>
>> yum update
>>
>> * Install the Xen packages from the centos-virt-xen-testing repo:
>>
>> yum install --enablerepo=centos-virt-xen-testing xen
>>
>> Keep in mind that there is still a bug in the upstream CentOS
>> new-kernel script which for some people consistently fails to add an
>> "initird" line to the Xen boot stanza.  Check /boot/grub/grub.conf;
>> the Xen stanza should look something like this:
>>
>> title CentOS (3.18.21-17.el6.x86_64)
>>  root (hd0,0)
>>  kernel /xen.gz dom0_mem=1024M,max:1024M cpuinfo com1=115200,8n1
>> console=com1,tty loglvl=all guest_loglvl=all
>>  module /vmlinuz-3.18.21-17.el6.x86_64 ro
>> root=/dev/mapper/VolGroup-lv_root rd_NO_LUKS LANG=en_US.UTF-8 rd_NO_MD
>> rd_LVM_LV=VolGroup/lv_swap SYSFONT=latarcyrheb-sun16 crashkernel=auto
>> rd_LVM_LV=VolGroup/lv_root  KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM rhgb
>> quiet
>>  module /initramfs-3.18.21-17.el6.x86_64.img
>>
>>
>>   -George
>> ___
>> CentOS-virt mailing list
>> CentOS-virt@centos.org
>> https://lists.centos.org/mailman/listinfo/centos-virt
>
> Hello
>
> I've attempted to upgrade today to xen 4.6 ( because of something which
> seems to be a reincarnation of
> http://lists.xen.org/archives/html/xen-devel/2014-01/msg02259.html ) and I
> noticed that the new xen-runtime package tries to bring in a whole bunch of
> other packages:

Those kinds of dependencies are automatically generated by rpmbuild
based on the linkages of the actual libraries.

I agree it would be nice to minimize the dependencies; but that would
take someone sitting down and figuring out which features / components
/ libraries / whatever were causing the dependencies, and either
disabling them or moving them to a separate package.  I don't have
time to do that at the moment; but I would be happy to help someone
else do so, and review pull requests to the xen package repos at
https://github.com/CentOS-virt7/xen.

 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

Re: [CentOS-virt] hoping to reschedule SIG meetings to Tuesdays 1500 UTC

[George Dunlap]

On Thu, Jan 14, 2016 at 11:52 AM, Sandro Bonazzola  wrote:
>
>
> On Tue, Jan 12, 2016 at 6:00 PM, Lokesh Mandvekar 
> wrote:
>>
>> I can't make it to the current schedule for alternate Tuesday 1400 UTC
>> meetings.
>>
>> I was hoping we could reschedule it to 1500 UTC on the same Tuesdays
>> instead, or
>> any other slot which could work for all.
>>
>> What do other members think?
>
>
>
> Ok for me

OK, well let's change the meeting then -- 1500 UTC (at the moment --
changes with British DST).

That makes it in one hour -- hope to see you guys there! :-)

 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

Re: [CentOS-virt] CentOS 6 Virt SIG Xen 4.6 packages available in centos-virt-xen-testing

[George Dunlap]

On Thu, Jan 21, 2016 at 12:01 PM, Peter <pe...@pajamian.dhs.org> wrote:
> On 15/01/16 05:57, George Dunlap wrote:
>> As mentioned yesterday, Xen 4.6 packages are now available for
>> testing.  These also include an update to libvirt 1.3.0, in line with
>> what's available for CentOS 7.  Please test, particularly the upgrade
>> if you can, and report any problems here.
>
> Per conversation in IRC, Xen 4.6 no longer includes xend and therefore
> no longer has the "xm" command.  This is problematic for people who may
> be using xm in various scripts on their host (such as home-brewed backup
> scripts).
>
> I think it's a bad idea to break this functionality without warning by
> allowing a simple "yum update" to remove it.  You will take a lot of
> people by surprise and cause such scripts to stop working, if people are
> running yum cron the situation becomes even worse.

Thanks, PJ, for your input.

Just to be clear:

1. In the Xen 4.4 packages (first released October 2014), xend was
disabled by default; so anyone using xend at the moment has already
manually intervened to enable deprecated functionality

2. In 4.4, the first time xm was executed, it printed this warning:
---
xend is deprecated and scheduled for removal. Please migrate to another
toolstack ASAP.

See http://wiki.xen.org/wiki/Choice_of_Toolstacks for information on
other alternatives, including xl which is designed to be a drop in
replacement for xm (http://wiki.xen.org/wiki/XL).
---

3. ...and on every subsequent invocation, it printed this warning:
"WARNING: xend/xm is deprecated"

I think this constitutes "warning" that the functionality was going to
break at some point. :-)

Also, in most cases "s/xm/xl/g;" Just Works; most people have reported
that changing from xm -> xl was pretty painless.  So this isn't like
upgrading from Python 2 to Python 3 (or QT 4 to 5, or...).

> I think that due to this lack of backwards compatibility with Xen 4.4
> and earlier versions it would be a good idea to not force the upgrade on
> people who are not wary of it.  I propose that the new packages carry
> the name "xen46" and they purposefully conflict with the old "xen"
> packages.  That will require people to take positive action to do the
> upgrade and hence avoid breaking systems unintentionally.

This would avoid breaking things for people still using xm, which
certainly has some value.  However it has some costs:

* The packages between C6 and C7 will now be slightly different,
increasing the maintenance burden.  This is not only in the spec file,
but also in all the associated scripting machinery for managing
packages in the CBS and smoke-testing packages before pushing them
publicly.

* Instructions for installing Xen are now differend between C6 and C7,
and slightly more complicated, as they have to explain about Xen 4.6
vs alternatives.

* Users who have heeded the warning and switched to xl will have to
make an extra effort to switch to Xen 4.6.  If they don't follow
centos-virt, they may not notice that there's a new package to upgrade
to.

I'm a developer, not a server admin, so I can't gauge how important
this issue is.  Before making such a change, I'd like to hear opinions
from other people in the community about how important (or not) it is
to avoid breaking xm, given the ample warning (>1 year) users have
had.

On the other hand, explicitly moving to a "xen${VER}" (both for C6 and
C7) would make it simpler for people to step up and maintain older
versions in parallel if anybody wanted to do so.

Thanks again, Peter, for bringing this up.

Peace,
 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

Re: [CentOS-virt] CentOS 6 Virt SIG Xen 4.6 packages available in centos-virt-xen-testing

[George Dunlap]

On Thu, Jan 21, 2016 at 1:28 PM, Phill Bandelow  wrote:
> Well when the last upgrade 4.2 > 4.4 went live and XM was disabled by
> default it took many hosts down without warning. 4.4 > 4.6  may cause the
> same issues. It's a dangerous upgrade for sure. Why can't 4.4 be LTS for C6?
> as it's the last build with XM. Any XSA patches should not be hard to
> backport. and maybe the optional xen4.6 for C6.

It's not a huge amount, but it is definitely time that I (and my
employer) would prefer to spend on other things.

As I've said elsewhere, this is a community project -- so if someone
wants to step up and maintain Xen 4.4 for CentOS 6, they are welcome.
I do agree that it shouldn't be a huge amount of work for someone to
pick this up, now that I've got the basic setup.  (And I'll definitely
still be around to help.)

If someone wanted to step up and maintain the 4.4 xen packages, I'd be
happy to hand that off, and just have xen46 for C6 and xen (v 4.6) for
C7.

 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

Re: [CentOS-virt] CentOS 6 Virt SIG Xen 4.6 packages available in centos-virt-xen-testing

[George Dunlap]

On Thu, Jan 21, 2016 at 3:39 PM, Johnny Hughes  wrote:
> On 01/21/2016 09:29 AM, Johnny Hughes wrote:
>> This is a community SIG .. and xenproject.org does NOT release XSAs for
>> 4.2.  The goal of Xen4centOS was to use an upstream LTS kernel and
>> update those as required to stay on an LTS.  Also to do every second
>> point release of xen (ie, 4.2, 4.4, 4.6).  All so we are longer term
>> than upstream, BUT we have supported code from upstream.
>>
>> So, the goal is to use supported code for the longest amount of time the
>> upsreams support them.  For xenproject.org .. they support the two
>> newest releases.  For kernel.org, they do a new kernel LTS about every 2
>> years.
>>
>> We don't have 5000 engineers to maintain community SIGs like they
>> maintain the distro.  We have to have supported code from upstream projects.
>>
>>
>
> So what does this mean ..
>
> xenproject.org supports 4.6 and 4.5 right now. (last 2 releases).

This isn't exactly right.

Recent releases have 18 months of "support" (meaning, bug fixes are
backported), and then another 18 months of "security backports", which
means only XSAs are backported [1], regardless of when or how many
releases have been made.  It just happens that most releases recently
have ended up taking about 9 months, which means at any given time you
have 2 in 'active support'; but that's mostly a coincidence. :-)

So 4.4 won't be getting any more point releases, but it should
continue to get XSAs through March 2017.  (This table [2] has it
ending in March 2016, but I'm pretty sure that's a mistake.)

 -George

[1] http://wiki.xenproject.org/wiki/Xen_Project_Maintenance_Releases

[2] http://wiki.xenproject.org/wiki/Xen_Project_Release_Features
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

Re: [CentOS-virt] CentOS 6 Virt SIG Xen 4.6 packages available in centos-virt-xen-testing

[George Dunlap]

On Thu, Jan 21, 2016 at 4:17 PM, Alvin Starr  wrote:
> My comment was targeted more at naming than support.
>
> I appreciate that there are vanishingly few resources to throw at support.
>
> I am glad to see any xen support for C7 and am thankful of all those who are
> putting in time to make things happen.
> I try to help out when I can but it is all too infrequently.

Yes, that's the way I understood you. :-)  It's an interesting model
to consider; as I said earlier, making that the standard (either
always having "xen44", "xen46", "xen48", or starting with "xen" and
then major upgrades getting renames as you suggest) has certain
advantages if we ever go the manpower to maintain two different
versions.

 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

Re: [CentOS-virt] CentOS 6 Virt SIG Xen 4.6 packages available in centos-virt-xen-testing

[George Dunlap]

On Thu, Jan 21, 2016 at 1:28 PM, Phill Bandelow  wrote:
> Well when the last upgrade 4.2 > 4.4 went live and XM was disabled by
> default it took many hosts down without warning. 4.4 > 4.6  may cause the
> same issues. It's a dangerous upgrade for sure. Why can't 4.4 be LTS for C6?
> as it's the last build with XM. Any XSA patches should not be hard to
> backport. and maybe the optional xen4.6 for C6.

The Xen Project does large of testing of Xen before updates and
releases; and I do a basic amount of smoke-testing before sending an
update.  But I don't really have the resources or the ability to do
the kind of extensive testing which would allow me to recommend
automatically pulling updates without testing them first, nor do I
envision any SIG ever having that amount of resource.  If that's the
kind of support you want, you might want to consider paying for either
XenServer or SLES. :-)

 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

Re: [CentOS-virt] Xen kernel-3.18.25-17 EL6 and EL7 needs testing

[George Dunlap]

On Tue, Jan 19, 2016 at 9:02 PM, Johnny Hughes  wrote:
> There is a new xen kernel for centos-6 and centos-7 the needs testing in:
>
> http://cbs.centos.org/repos/virt6-xen-common-testing/x86_64/os/Packages/
>
> and
>
> http://cbs.centos.org/repos/virt7-xen-common-testing/x86_64/os/Packages/

Thanks, Johnny!

Just a minor question about workflow.  I had understood that CentOS
wanted the CBS itself to only be used for SIG dev testing; and that
for wider testing they wanted to use buildlogs.  And so ideally after
making sure the basics were in place, you would have tagged it with
-testing, and then sent out an announcement asking people to test it
by doing "yum --enablerepo=centos-virt-xen-testing update kernel".
Was that the idea, or did I miss something?

Thanks,
 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

[CentOS-virt] Virt SIG Xen updates for XSAs 167-169

[George Dunlap]

xen-4.4.3-10.el6 and xen-4.6.0-9.el7, which contain patches for XSAs
167-169, are on their way to CentOS 6 and CentOS 7 Virt Sig Xen
mirrors, respectively.

As a reminder, this is the last security update for xen-4.4.  Xen 4.6
for CentOS 6 is already available in centos-virt-xen-testing, and we
will be pushing it to the main (mirrors) repository sometime this
week.

Peace,
 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

[CentOS-virt] CentOS 6 Virt SIG Xen 4.6 packages available in centos-virt-xen-testing

[George Dunlap]

As mentioned yesterday, Xen 4.6 packages are now available for
testing.  These also include an update to libvirt 1.3.0, in line with
what's available for CentOS 7.  Please test, particularly the upgrade
if you can, and report any problems here.

To upgrade:

yum update --enablerepo=centos-virt-xen-testing

To install from scratch:

* Install centos-release-xen from centos-extras

yum install centos-release-xen

* Update to get the new kernel:

yum update

* Install the Xen packages from the centos-virt-xen-testing repo:

yum install --enablerepo=centos-virt-xen-testing xen

Keep in mind that there is still a bug in the upstream CentOS
new-kernel script which for some people consistently fails to add an
"initird" line to the Xen boot stanza.  Check /boot/grub/grub.conf;
the Xen stanza should look something like this:

title CentOS (3.18.21-17.el6.x86_64)
root (hd0,0)
kernel /xen.gz dom0_mem=1024M,max:1024M cpuinfo com1=115200,8n1
console=com1,tty loglvl=all guest_loglvl=all
module /vmlinuz-3.18.21-17.el6.x86_64 ro
root=/dev/mapper/VolGroup-lv_root rd_NO_LUKS LANG=en_US.UTF-8 rd_NO_MD
rd_LVM_LV=VolGroup/lv_swap SYSFONT=latarcyrheb-sun16 crashkernel=auto
rd_LVM_LV=VolGroup/lv_root  KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM rhgb
quiet
module /initramfs-3.18.21-17.el6.x86_64.img


 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

Re: [CentOS-virt] Welcoming a new SIG member :)

[George Dunlap]

On Tue, Jan 12, 2016 at 4:49 PM, Lokesh Mandvekar
 wrote:
> Virt SIG folks, please join me in welcoming our latest SIG member, Marianne 
> Lombard (username: jehane).
> She's been a Fedora contributor for quite sometime already, and will now be
> helping to ensure I'm not being a bottleneck RE: docker on CentOS virt :)
>
> Welcome aboard, Marianne.

Welcome!  Look forward to meeting you at the next Virt SIG meeting.

 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

Re: [CentOS-virt] Missing module grub entry in xen-4.4.3-9 & boot issues

[George Dunlap]

On Sun, Dec 20, 2015 at 11:31 AM, Phill Bandelow  wrote:
> HI,
>
> We've started to see several issues with the Xen releases. Going back to
> basics I've used this guide
> https://wiki.centos.org/HowTos/Xen/Xen4QuickStart
>
> Once the install process is complete the grub.conf looks like this:
>
> default=0
> timeout=5
> splashimage=(hd0,0)/boot/grub/splash.xpm.gz
> hiddenmenu
> title CentOS (3.18.21-17.el6.x86_64)
> root (hd0,0)
> kernel /boot/xen.gz dom0_mem=1024M,max:1024M cpuinfo com1=115200,8n1
> console=com1,tty loglvl=all guest_loglvl=all
> module /boot/vmlinuz-3.18.21-17.el6.x86_64 ro root=/dev/vda1
> rd_NO_LUKS rd_NO_LVM LANG=en_US.UTF-8 rd_NO_MD SYSFONT=latarcyrheb-sun16
> crashkernel=auto  KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM rhgb quiet
> title CentOS (2.6.32-573.12.1.el6.x86_64)
> root (hd0,0)
> kernel /boot/vmlinuz-2.6.32-573.12.1.el6.x86_64 ro root=/dev/vda1
> rd_NO_LUKS rd_NO_LVM LANG=en_US.UTF-8 rd_NO_MD SYSFONT=latarcyrheb-sun16
> crashkernel=auto  KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM rhgb quiet
> initrd /boot/initramfs-2.6.32-573.12.1.el6.x86_64.img
> title CentOS (2.6.32-358.el6.x86_64)
> root (hd0,0)
> kernel /boot/vmlinuz-2.6.32-358.el6.x86_64 ro
> root=UUID=71b203ab-36ea-4aa8-9ba3-78e4109f0ca4 rd_NO_LUKS rd_NO_LVM
> LANG=en_US.UTF-8 rd_NO_MD SYSFONT=latarcyrheb-sun16 crashkernel=auto
> KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM rhgb quiet
> initrd /boot/initramfs-2.6.32-358.el6.x86_64.img
>
> As you can see the missing module line. If i manually run grub-bootxen.sh
> nothing changes.

Thanks for the detailed report.

The initrd thing is a bug in the upstream script that makes the grub
config; I haven't seen the behavior, so I haven't been able to track
down what the problem is, but other people have[1].

CentOS 7 uses grub2, which comes with its own grub-generation code
which is more reliable.

[1] marc.info/?i=<563670f4.9030...@karlos.cz>

> Manually adding the missing module entry:
>
> module /boot/initramfs-3.18.21-17.el6.x86_64.img
>
> Causes the following:
>
> https://www.dropbox.com/s/ley5nj29ubwqogc/Screenshot%202015-12-20%2011.10.11.png?dl=0
>
> Disabling APIC gives the following console output:
>
> https://www.dropbox.com/s/a6zgioxl9xpg20y/Screenshot%202015-12-20%2011.15.29.png?dl=0
>
> Now i know this is inside a KVM virtual machine, however we are starting to
> see this issue on at least 7 standard dedicated servers.

You're starting to see that exact error message, you mean, about the
timer not connected to the IOAPIC?

In any case, it would be more helpful if you could manage to get a
serial console output from one of the physical boxes where you've got
a problem.  A lot of servers have built-in serial consoles you can
attach to over the network; otherwise, you can take a look at this
page:

http://wiki.xen.org/wiki/Xen_Serial_Console

Thanks,
 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

Re: [CentOS-virt] Missing module grub entry in xen-4.4.3-9 & boot issues

[George Dunlap]

On Sun, Dec 20, 2015 at 5:11 PM, PJ Welsh  wrote:
> I've also had a few Xen systems grub entry issues. I'm not yet sure what
> triggers the events, but I do think there *may* be a correlation to the
> "/boot" part. I've found the Xen servers that have "/boot" before any of the
> the lines like "/boot/xen.gz" ended up missing complete grub entries. Not
> sure it's 100% true. Anyone else comment?

I can't quite figure out what you mean by having a "/boot" before
other lines.  Could you attach copies of "normal" vs "buggy" grub.conf
files?

 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

[CentOS-virt] CentOS 7 libvirt-1.3.0-1 coming to virt-xen buildlogs

[George Dunlap]

Centos 7.2 has updated its version of libvirt to 1.2.17, which ends up
getting installed in preference to the previous virt-xen libvirt
package (1.2.15).

I've merged in the most recent Fedora libvirt package, 1.3.0, smoked
tested it, and pushed it to buildlogs, which can be accessed by adding
--enablerepo=centos-virt-xen-testing (after installing the CentOS 7
centos-release-xen package).  Please test and let me know if there are
any problems.

 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

[CentOS-virt] XSAs: Updated CentOS 6 xen and kernel packages in buildlogs

[George Dunlap]

xen-4.4.3-9 and kernel-3.18.21-17 (unsigneg) are now on
buildlogs.centos.org, and signed packages should be making their way
through the mirror system in the near future.

Updated package sources can be found in the virt sig area on CentOS:

https://github.com/CentOS-virt7/xen
https://github.com/CentOS-virt7/xen-kernel

The packages contain updates for XSAs 155, 157, 164, 165, and 166
(released today), as well as patches for XSA-142 and an update to
XSA-158.

For those urgent to install the updated packages, you can get them
from buildlogs by enabling the centos-virt-xen-testing repository:

yum --enablerepo=centos-virt-xen-testing update

Please report any issues here on the list.

 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

Re: [CentOS-virt] win2008r2 update on centos 6 host made system unbootable

[George Dunlap]

On Wed, Dec 9, 2015 at 8:31 PM, Patrick Bervoets
 wrote:
>
>
> Op 09-12-15 om 14:23 schreef Dennis Jacobfeuerborn:
>>
>> Yes, this is a CentOS 6 Host using regular libvirt based virtualization.
>> The Suse driver is apparently an optional update that gets delivered using
>> the regular Microsoft update mechanism. It's hard to believe that they
>> didn't catch a completely broken driver during QA so my hypothesis is that
>> maybe the new Virtio driver is incompatible only with the older Kernel of
>> CentOS 6 and that this wasn't properly tested. To verify this one could
>> check if the same thing happens on a CentOS 7 Host but at the moment I'm to
>> busy the check this. Regards, Dennis
>
>
> Regrettably Microsoft has picked up the habbit of giving out buggy patches.
> Sysadmins are becoming betatesters.

Well to be fair to Microsoft, the only reason SuSE driver would even
load on RHEL is if the virtio devices running on SuSE look to Windows
sufficiently like the virtio devices running on RHEL.  It's not the
normal thing to have two completely different vendors writing drivers
for nearly identical (yet incompatible) hardware, so it's not terribly
surprising that they didn't start out with checks for this kind of
thing.

 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

Re: [CentOS-virt] Xen4CentOS and XSA-142

[George Dunlap]

On Thu, Dec 10, 2015 at 6:49 AM, Sarah Newman  wrote:
> It looks like no XSA-142 patch, which is "libxl fails to honour readonly flag 
> on disks with qemu-xen" has been applied to Xen4CentOS. I assume this
> was on purpose?

No, indeed it wasn't on purpose.  Sorry that it dropped through the cracks.

> If not, I can have someone try adding the original patch from 
> http://xenbits.xen.org/xsa/advisory-142.html and some variant of the commit 
> from
> ef6cb76026628e26e3d1ae53c50ccde1c3c78b1b 
> http://xen.1045712.n5.nabble.com/xen-master-libxl-relax-readonly-check-introduced-by-XSA-142-fix-td5729704.html
>  .

If you could send a pull request to
https://github.com/CentOS-virt7/xen with those two patches imported
into the patchqueue (and give me any feedback on the README which
explains how to do it), that would be awesome.  (Feel free to send a
pull request pointing to a non-github git tree via e-mail as well if
you wish.)

Otherwise I'll try to get to it next week.

 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

Re: [CentOS-virt] new install of Xen 4.6 hangs on Loading initial ramdisk

[George Dunlap]

On Tue, Dec 8, 2015 at 4:17 PM, President <presid...@caldwellglobal.com> wrote:
> Not sure if this actually made it to the list the first time.
>
>
> Here is the SERIAL output (bottom of message after your questions).
> Googling the error indicates it's something people ran into a few years back
> but was supposedly fixed.  Any ideas?
>
>
> I can verify that if I REMOVE the second CPU, it boots into Xen kernel no
> problem.  The CPU itself doesn't matter, as I can swap either CPU into the
> first slot, and it boots.  Only if there is a second CPU does it fail.

Great, thanks for the report.  This looks like a bug in upstream Xen
-- would you mind re-posting this (with the serial output) on the
xen-users mailing list?  That will get more eyeballs on the problem.

 -George

>
>
> -Original message-
> From: George Dunlap <dunl...@umich.edu>
> Sent: Monday 30th November 2015 6:00
> To: Discussion about the virtualization on CentOS <centos-virt@centos.org>
> Subject: Re: [CentOS-virt] new install of Xen 4.6 hangs on Loading initial
> ramdisk
>
>
>
> On Fri, Nov 27, 2015 at 11:18 PM, Craig Thompson
> <presid...@caldwellglobal.com> wrote:
>>
>> First post to this list.  I would appreciate some help on this issue.
>>
>> As background, I installed CentOS 7 on a Dell server, and then ran the
>> following commands:
>>
>> yum update
>> http://buildlogs.centos.org/centos/7/virt/x86_64/xen/centos-release-xen-7-11.el7.x86_64.rpm
>> yum --enablerepo=centos-virt-xen-testing update
>> yum --enablerepo=centos-virt-xen-testing install xen
>>
>> Doing that, I was able to successfully install Xen, create a virtual
>> machine with its own HVM setup, logical volume, etc. and boot it just fine.
>>
>> I then tried to do the same on an IBM x3550 server I’m trying to install
>> with CentOS 7.  The CentOS 7 install went just fine.  I can boot into the
>> standard kernel and have a working machine.  But after running the commands
>> above to install the Xen hypervisor, the machine hangs on boot for a few
>> moments after displaying the lines below and then reboots in a loop over and
>> over and over:
>>
>> Loading Xen 4.6.0-2.el7 …
>> Loading Linux 3.18.21-16.el7.x86_64 …
>> Loading initial ramdisk …
>>
>> It never gets beyond that.  If I choose the stock kernel (no Xen) from the
>> Grub menu, it will continue to boot into that just fine.
>>
>> My grub.cfg file has these entries of note:
>>
>>  multiboot /xen-4.6.0-2.el7.gz placeholder  dom0_mem=1024M,max:1024M
>> cpuinfo com1=115200,8n1 console=com1,tty loglvl=all guest_loglvl=all
>> ${xen_rm_opts}
>> echo'Loading Linux 3.18.21-16.el7.x86_64 ...'
>> module  /vmlinuz-3.18.21-16.el7.x86_64 placeholder
>> root=UUID=9dc18146-f9b3-41cc-ba9c-7314689abcde ro crashkernel=auto debug
>> irqpoll ipv6.disable=1 console=hvc0 earlyprintk=xen nomodeset
>> echo'Loading initial ramdisk ...'
>> module  --nounzip   /initramfs-3.18.21-16.el7.x86_64.img
>>
>>
>> What I have tried:
>>
>> 1) adding debug into the vmlinuz line
>> 2) disabling ipv6 in that line
>> 3) adding root=UUID=9dc18146-f9b3-41cc-ba9c-7314689abcde to the last line
>> AFTER /initramfs ….
>>
>> Nothing so far has made any difference.  Obviously the process works, as
>> it works for me just fine on the Dell server.
>>
>> Underlying this machine is a SATA RAID 1 PCI card with two SSD drives
>> attached in a RAID 1 mirror.  Not that that should matter, but I’m including
>> it for reference. As noted previously, it boots into the stock kernel just
>> fine.
>>
>> Any help would be appreciated.
>
>
> Thanks for the testing and the report.
>
> Have you tried booting the Xen4CentOS kernel (Linux-3.18.21-16) by itself
> (i.e., not under Xen)?
>
> Also, is there any chance you could get the output of a serial console?
> That's pretty critical for debugging this sort of thing.
> CentOS-virt mailing list
>
> 
>
> ###  No such file or directory opening port
> (XEN) Bad console= option 'tty'
>  Xen 4.6.0-2.el7
> (XEN) Xen version 4.6.0-2.el7 (mockbu...@centos.org) (gcc (GCC) 4.8.3
> 20140911 (Red Hat 4.8.3-9)) debug=n Tue Nov  3 17:23:39 UTC 2015
> (XEN) Latest ChangeSet: Mon Oct 19 12:05:21 2015 +0100 git:36b6fe9-dirty
> (XEN) Bootloader: GRUB 2.02~beta2
> (XEN) Command line: placeholder dom0_mem=1024M,max:1024M cpuinfo
> com1=115200,8n1 console=com1,tty loglvl=all guest_loglvl=all
> (XEN) Video information:
> (XEN)  VGA is text mode 80x25, font 8x16
> (XEN)  VBE/DDC methods: V2; EDI

[CentOS-virt] Xen build with XSAs through 163 in progress

[George Dunlap]

Just a heads-up: A Xen package with XSAs through 163 is on its way
through the build system.  I'll send an announcement when I've tagged
it as ready to be propagated to the mirrors.

As with the last XSA update, it will depend on having manually updated
to the new Virt SIG repository layout.  If you haven't already please
run the following in preparation:

yum install 
http://buildlogs.centos.org/centos/6/virt/x86_64/xen/centos-release-xen-7-11.el6.x86_64.rpm

(And note that this package depends on a package from centos-extras,
so if you have that repo disabled by default you'll need to enable it
to perform the above command.)

 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

Re: [CentOS-virt] Xen build with XSAs through 163 in progress

[George Dunlap]

On Tue, Dec 8, 2015 at 12:23 PM, George Dunlap <dunl...@umich.edu> wrote:
> Just a heads-up: A Xen package with XSAs through 163 is on its way
> through the build system.  I'll send an announcement when I've tagged
> it as ready to be propagated to the mirrors.
>
> As with the last XSA update, it will depend on having manually updated
> to the new Virt SIG repository layout.  If you haven't already please
> run the following in preparation:
>
> yum install 
> http://buildlogs.centos.org/centos/6/virt/x86_64/xen/centos-release-xen-7-11.el6.x86_64.rpm
>
> (And note that this package depends on a package from centos-extras,
> so if you have that repo disabled by default you'll need to enable it
> to perform the above command.)

...and the updated packages have now been signed and pushed to
mirror.centos.org.

 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

Re: [CentOS-virt] new install of Xen 4.6 hangs on Loading initial ramdisk

[George Dunlap]

On Fri, Nov 27, 2015 at 11:18 PM, Craig Thompson <
presid...@caldwellglobal.com> wrote:

> First post to this list.  I would appreciate some help on this issue.
>
> As background, I installed CentOS 7 on a Dell server, and then ran the
> following commands:
>
> yum update
> http://buildlogs.centos.org/centos/7/virt/x86_64/xen/centos-release-xen-7-11.el7.x86_64.rpm
> yum --enablerepo=centos-virt-xen-testing update
> yum --enablerepo=centos-virt-xen-testing install xen
>
> Doing that, I was able to successfully install Xen, create a virtual
> machine with its own HVM setup, logical volume, etc. and boot it just fine.
>
> I then tried to do the same on an IBM x3550 server I’m trying to install
> with CentOS 7.  The CentOS 7 install went just fine.  I can boot into the
> standard kernel and have a working machine.  But after running the commands
> above to install the Xen hypervisor, the machine hangs on boot for a few
> moments after displaying the lines below and then reboots in a loop over
> and over and over:
>
> Loading Xen 4.6.0-2.el7 …
> Loading Linux 3.18.21-16.el7.x86_64 …
> Loading initial ramdisk …
>
> It never gets beyond that.  If I choose the stock kernel (no Xen) from the
> Grub menu, it will continue to boot into that just fine.
>
> My grub.cfg file has these entries of note:
>
>  multiboot /xen-4.6.0-2.el7.gz placeholder  dom0_mem=1024M,max:1024M
> cpuinfo com1=115200,8n1 console=com1,tty loglvl=all guest_loglvl=all
> ${xen_rm_opts}
> echo'Loading Linux 3.18.21-16.el7.x86_64 ...'
> module  /vmlinuz-3.18.21-16.el7.x86_64 placeholder
> root=UUID=9dc18146-f9b3-41cc-ba9c-7314689abcde ro crashkernel=auto debug
> irqpoll ipv6.disable=1 console=hvc0 earlyprintk=xen nomodeset
> echo'Loading initial ramdisk ...'
> module  --nounzip   /initramfs-3.18.21-16.el7.x86_64.img
>
>
> What I have tried:
>
> 1) adding debug into the vmlinuz line
> 2) disabling ipv6 in that line
> 3) adding root=UUID=9dc18146-f9b3-41cc-ba9c-7314689abcde to the last line
> AFTER /initramfs ….
>
> Nothing so far has made any difference.  Obviously the process works, as
> it works for me just fine on the Dell server.
>
> Underlying this machine is a SATA RAID 1 PCI card with two SSD drives
> attached in a RAID 1 mirror.  Not that that should matter, but I’m
> including it for reference. As noted previously, it boots into the stock
> kernel just fine.
>
> Any help would be appreciated.
>

Thanks for the testing and the report.

Have you tried booting the Xen4CentOS kernel (Linux-3.18.21-16) by itself
(i.e., not under Xen)?

Also, is there any chance you could get the output of a serial console?
That's pretty critical for debugging this sort of thing.

 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

[CentOS-virt] No separate XSA-162 package

[George Dunlap]

Hey all, just a heads-up: XSA-162 [1] was released to the public this
morning at 0600 UTC.  It is, however, a bug in a non-default network
card with a simple work-around (don't use that network card).  Since
there are a large number of updates due next week, and this is a
fairly low-priority one, I decided not to do a package release
specifically for it, and to include all the updates (through XSA-163)
in the release I'll do next week.

Peace,
 -George

[1] http://xenbits.xen.org/xsa/advisory-162.html
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

Re: [CentOS-virt] CentOS 6 Xen package update (including XSA-156)

[George Dunlap]

On Thu, Nov 19, 2015 at 12:28 PM, George Dunlap <dunl...@umich.edu> wrote:
> On Wed, Nov 18, 2015 at 1:31 PM, Pasi Kärkkäinen <pa...@iki.fi> wrote:
>> On Wed, Nov 18, 2015 at 02:20:49PM +0200, Manuel Wolfshant wrote:
>>> On 11/18/2015 02:08 PM, Pasi Kärkkäinen wrote:
>>> >Hello,
>>> >
>>> >On Sun, Nov 15, 2015 at 06:42:18PM +0200, Pasi Kärkkäinen wrote:
>>> >>On Sun, Nov 15, 2015 at 02:04:58PM +0200, Pasi Kärkkäinen wrote:
>>> >>>On Thu, Nov 12, 2015 at 02:00:27PM +, George Dunlap wrote:
>>> >>>>So going forward, we're moving the CentOS 6 Xen packages from the
>>> >>>>custom "xen4" repos that were introduced several years ago, to repos
>>> >>>>based on its position as a sub-project of the Virt Sig.  That will
>>> >>>>make things consistent between all the sigs, as well as between CentOS
>>> >>>>6 and 7 Xen packages.
>>> >>>>
>>> >>>>Unfortunately, XSA-156 came up rather suddenly and is a bit blocked by
>>> >>>>this transition.
>>> >>>>
>>> >>>>So please help us test the new repository structure, so that we can
>>> >>>>with conscience push the updates to xen4 users in general.
>>> >>>>
>>> >>>Seems to work for me!
>>> >>>
>>> >>>
>>> >>Except now on another system I see this problem:
>>> >>
>>> >Anyone else seeing this libvirt-python problem with virt-manager and/or 
>>> >virt-viewer ?
>>> >
>>> >(happens on a freshly installed system, so no earlier libvirt rpms 
>>> >installed)
>>> >
>>> It tries to install half of the OS, but it works for me.  It seems
>>> that your yum does not like that you already have
>>> libvirt-client-1.2.15-3.el6.x86_64. Mine is happy to bring in
>>> libvirt-{python,client}-0.10.2-54.el6_7.2.x86_64 from updates
>>>
>>
>> libvirt-{python,client}-0.10.2-54.el6_7.2.x86_64 are the centos core 
>> packages,
>> while the libvirt-client-1.2.15-3.el6.x86_64 is the Virt SIG provided one,
>> which has Xen support enabled.
>>
>> So I need the 1.2.15-3 versions, but it seems libvirt-python is not included 
>> in the Virt SIG built ones..
>>
>> So that's an issue/problem..
>
> Right -- for 1.2.12 they decided to  have libvirt-python be a
> completely separate package.  I  had apparently started getting that
> package built at some time in the distant past but never finished.
>
> I've cloned & build Fedora's libvirt-python-1.2.15 (which is pretty
> much what I did for libvirt-1.2.15); it should show up in buildlogs in
> an hour or two.  Once that's in, if you go "yum
> --enablerepo=centos-virt-xen-testing virt-manager", it should install.
> (At least, the version in CBS works for me.)
>
> Let me know if it works.

OK, well in the absence of testing, it works for me, so I've tagged it
to go to the main repo, and Johnny will be pushing the updated
centos-release-xen to centos-extras tonight or tomorrow.

 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

Re: [CentOS-virt] CentOS 6 Xen package update (including XSA-156)

[George Dunlap]

On Wed, Nov 18, 2015 at 1:31 PM, Pasi Kärkkäinen <pa...@iki.fi> wrote:
> On Wed, Nov 18, 2015 at 02:20:49PM +0200, Manuel Wolfshant wrote:
>> On 11/18/2015 02:08 PM, Pasi Kärkkäinen wrote:
>> >Hello,
>> >
>> >On Sun, Nov 15, 2015 at 06:42:18PM +0200, Pasi Kärkkäinen wrote:
>> >>On Sun, Nov 15, 2015 at 02:04:58PM +0200, Pasi Kärkkäinen wrote:
>> >>>On Thu, Nov 12, 2015 at 02:00:27PM +, George Dunlap wrote:
>> >>>>So going forward, we're moving the CentOS 6 Xen packages from the
>> >>>>custom "xen4" repos that were introduced several years ago, to repos
>> >>>>based on its position as a sub-project of the Virt Sig.  That will
>> >>>>make things consistent between all the sigs, as well as between CentOS
>> >>>>6 and 7 Xen packages.
>> >>>>
>> >>>>Unfortunately, XSA-156 came up rather suddenly and is a bit blocked by
>> >>>>this transition.
>> >>>>
>> >>>>So please help us test the new repository structure, so that we can
>> >>>>with conscience push the updates to xen4 users in general.
>> >>>>
>> >>>Seems to work for me!
>> >>>
>> >>>
>> >>Except now on another system I see this problem:
>> >>
>> >Anyone else seeing this libvirt-python problem with virt-manager and/or 
>> >virt-viewer ?
>> >
>> >(happens on a freshly installed system, so no earlier libvirt rpms 
>> >installed)
>> >
>> It tries to install half of the OS, but it works for me.  It seems
>> that your yum does not like that you already have
>> libvirt-client-1.2.15-3.el6.x86_64. Mine is happy to bring in
>> libvirt-{python,client}-0.10.2-54.el6_7.2.x86_64 from updates
>>
>
> libvirt-{python,client}-0.10.2-54.el6_7.2.x86_64 are the centos core packages,
> while the libvirt-client-1.2.15-3.el6.x86_64 is the Virt SIG provided one,
> which has Xen support enabled.
>
> So I need the 1.2.15-3 versions, but it seems libvirt-python is not included 
> in the Virt SIG built ones..
>
> So that's an issue/problem..

Right -- for 1.2.12 they decided to  have libvirt-python be a
completely separate package.  I  had apparently started getting that
package built at some time in the distant past but never finished.

I've cloned & build Fedora's libvirt-python-1.2.15 (which is pretty
much what I did for libvirt-1.2.15); it should show up in buildlogs in
an hour or two.  Once that's in, if you go "yum
--enablerepo=centos-virt-xen-testing virt-manager", it should install.
(At least, the version in CBS works for me.)

Let me know if it works.

Thanks,
 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

Re: [CentOS-virt] CentOS 6 Xen package update (including XSA-156)

[George Dunlap]

On Thu, Nov 19, 2015 at 12:28 PM, George Dunlap <dunl...@umich.edu> wrote:
> I've cloned & build Fedora's libvirt-python-1.2.15 (which is pretty
> much what I did for libvirt-1.2.15); it should show up in buildlogs in
> an hour or two.  Once that's in, if you go "yum
> --enablerepo=centos-virt-xen-testing virt-manager", it should install.
> (At least, the version in CBS works for me.)

Also -- I added "install virt-manager" to my smoke-test scripts, and
was rather surprised to find out that it succeeds on CentOS 7 --
because apparently libvirt-python-1.2.8 from the C7 base repo will
happily install along with libvirt-python-1.2.15.  Out of curiosity,
have you tried to see if it works?

 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

[CentOS-virt] CentOS 6 Xen package update (including XSA-156)

[George Dunlap]

So going forward, we're moving the CentOS 6 Xen packages from the
custom "xen4" repos that were introduced several years ago, to repos
based on its position as a sub-project of the Virt Sig.  That will
make things consistent between all the sigs, as well as between CentOS
6 and 7 Xen packages.

Unfortunately, XSA-156 came up rather suddenly and is a bit blocked by
this transition.

So please help us test the new repository structure, so that we can
with conscience push the updates to xen4 users in general.

To update to the new repository structure, install the
centos-release-xen package directly from the new repo:

 yum update 
http://mirror.centos.org/centos/6/virt/x86_64/xen/centos-release-xen-7-11.el6.x86_64.rpm

This should replace the xen4 repositories with the new virt sig
repositories.  Now do a 'yum update':

yum update

This should pull in the Xen 4.4.3-6 package, which contains XSA-156
(and all other packages).

If everything works as planned, we'll push the new centos-release-xen
to centos-extras, and then everyone else will be moved to the new
repos the next time they do an update.

 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

Re: [CentOS-virt] CentOS 6 Xen package update (including XSA-156)

[George Dunlap]

On Thu, Nov 12, 2015 at 2:03 PM, Manuel Wolfshant
<wo...@nobugconsulting.ro> wrote:
> On 11/12/2015 04:00 PM, George Dunlap wrote:
>>
>> To update to the new repository structure, install the
>> centos-release-xen package directly from the new repo:
>>
>>   yum
>> updatehttp://mirror.centos.org/centos/6/virt/x86_64/xen/centos-release-xen-7-11.el6.x86_64.rpm
>>
>> This should replace the xen4 repositories with the new virt sig
>
>
> [root@xenh4bis ~]# yum update -y
> http://mirror.centos.org/centos/6/virt/x86_64/xen/centos-release-xen-7-11.el6.x86_64.rpm
> Loaded plugins: fastestmirror, presto
> Setting up Update Process
> centos-release-xen-7-11.el6.x86_64.rpm | 6.0 kB 00:00
> Examining /var/tmp/yum-root-DzSL_q/centos-release-xen-7-11.el6.x86_64.rpm:
> 10:centos-release-xen-7-11.el6.x86_64
> Marking /var/tmp/yum-root-DzSL_q/centos-release-xen-7-11.el6.x86_64.rpm as
> an update to 10:centos-release-xen-6-4.el6.centos.x86_64
> Loading mirror speeds from cached hostfile
>  * epel: fedora.mirrors.telekom.ro
> base |  951 B 00:00
> updates |  951 B 00:00
> Resolving Dependencies
> --> Running transaction check
> ---> Package centos-release-xen.x86_64 10:6-4.el6.centos will be updated
> ---> Package centos-release-xen.x86_64 10:7-11.el6 will be an update
> --> Processing Dependency:
> /etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-SIG-Virtualization for package:
> 10:centos-release-xen-7-11.el6.x86_64
> --> Processing Dependency:
> /etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-SIG-Virtualization for package:
> 10:centos-release-xen-7-11.el6.x86_64
> --> Finished Dependency Resolution
> Error: Package: 10:centos-release-xen-7-11.el6.x86_64
> (/centos-release-xen-7-11.el6.x86_64)
>Requires: /etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-SIG-Virtualization
>  You could try using --skip-broken to work around the problem
>  You could try running: rpm -Va --nofiles --nodigest

Do you have the centos-extras repo enabled?  The key in question is in
the centos-release-virt-common package, which is in the centos-extras
repo.

 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

[CentOS-virt] CentOS 7 Xen 4.6.0 packages available on buildlogs

[George Dunlap]

At long last, we have the packages and the infrastructure set up in
what will be (hopefully) the final form for the CentOS 7 Virt SIG Xen
packages.  Please help us by testing the packages and the
infrastructure.

To install the Virt SIG Xen repositories, install the CentOS 7
centos-release-xen package directly from buildlogs:

yum update 
http://buildlogs.centos.org/centos/7/virt/x86_64/xen/centos-release-xen-7-11.el7.x86_64.rpm

Because the CentOS packages aren't released yet, they are only
available on buildlogs, which are in the (disable-default)
centos-virt-xen-testing repository.

So first install the kernel:

yum --enablerepo=centos-virt-xen-testing update

Then install xen:

yum --enablerepo=centos-virt-xen-testing install xen

The version we're starting with is Xen 4.6, which has good systemd
support as well as aarch64 support.  The version on buildlogs has XSAs
through 156 applied.

Libvirt is also available, for those who are so inclined.

Please report any bugs on this list.

Thanks,
 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

[CentOS-virt] Updated packages for XSA-156 to be built starting at 12:01am UTC

[George Dunlap]

As you may have noticed, XSA-156 is due to be released publicly at
12:01am tomorrow (10 November).

I've prepped packages, and before I leave today will set a script to
send them to the CBS at 12:01 exactly.  Packages should end up in
virt6-xen-44-candidate within probably half an hour after that.  If
something goes wrong, I'll try to have it sorted out when I come in
tomorrow morning (usually around 10am UTC).

 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

Re: [CentOS-virt] CVE-2015-7835

[George Dunlap]

On Wed, Nov 4, 2015 at 4:11 PM, Jens Larsson  wrote:
>>> There was new packages (4.4.3-3) released on Oct 29, but they don't
>>> address the CVE-2015-7835 problems. Does anyone have news about a
>>> rebuild with this fix applied? Or should we make our own build?
>>
>> Actually they do includu CVE-2015-7835 (aka XSA-148) -- I just made a
>> mistake when I made the changelog.  Sorry about that.
>>
>>  -George
>
> Ah, I thought I was careful before posting and even checked the source
> RPM. But of course I did it wrong. The patch is there all right...
>
> Sorry for the noise. And thanks for all the good work on this project!

No problem -- definitely rather err on the side of "unnecessary noise"
rather than "missed an important security update". :-)

Peace,
 -George
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt