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 &c.  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&paste 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
sclo/x86_64/rh/rh-p

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, &c)
3) Kernel testing -- device driver bugs, &c

#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] virsh support for TPM?

[George Dunlap]

On Tue, Sep 11, 2018 at 4:16 PM Dag Nygren  wrote:
>
> Hi again!
>
> Succeeded in creating vtpmmgr-stubdom.gz from
> the source RPM with some shortcuts.
>
> ow the next problem seems to be that the
> libvirt we have will not support the XEN vtpm:s
>
> For example:
> virsh dumpxml 
>
> will not contain any info on the vtpm :-(
>
> Am I really the first one around with a need for
> TPM support in the VM:s ??

Almost certainly the first Virt SIG user to try it. :-)

4 years ago, I don't think any of the big enterprises contributing to
Xen (Citrix, SuSE, Oracle) cared about vTPMs; only niche players like
the NSA, who typically downloaded and ran things themselves.  (This is
probably why vTPM is disabled in RH's KVM.)

This will be changing in the future, as Windows requires vTPM (version
2 in fact) for some features, so that's in the process of being
implemented.  It will take a bit for that to make its way into
upstream however.

In the mean time, you can probably get much better technical answers
to your questions by asking on the xen-devel mailing list; and if you
manage to improve the CentOS vTPM support, please consider feeding
your changes back by sending pull requests to
https://github.com/CentOS-virt7/xen .

Peace,
 -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 dev

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, &c.
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  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&D
>
> 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 ]---
> [  147.424117] --

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  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

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

[George Dunlap]

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.

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

[CentOS-virt] Xen 4.6.6-7 packages in virt-testing

[George Dunlap]

I've tagged the 4.6.6-7, which contain XSAs 246 and 247, in testing;
they should show up in virt-testing soon.  Please report any issues;
I'll probably tag for release tomorrow (to show up Thursday).

 -George
___
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
> https://lists.centos.org/mailman/listinfo/centos-vi

[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

[CentOS-virt] Patch for SELinux on Xen 4.7+

[George Dunlap]

Sarah / Anthony,

Attached is the patch I mentioned in the meeting today.

 -George
From 77d764ed329f07494fe18a07b3f870ec007f8bf4 Mon Sep 17 00:00:00 2001
From: George Dunlap 
Date: Tue, 7 Jun 2016 11:23:02 +0100
Subject: [PATCH] libxc: Try /proc/xen/privcmd on EACCES as well

/proc/xen/privcmd is deprecated in favor of /dev/xen/privcmd; but at
the moment the SELinux rules in CentOS 7 are outdated and only know
about /proc; access to the /dev node will result in EACCES.

As a temporary work-around, try to read the /proc path if opening the /dev
path fails with EACCES.

Signed-off-by: George Dunlap 
---
 tools/libs/call/linux.c  | 2 +-
 tools/libs/foreignmemory/linux.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/libs/call/linux.c b/tools/libs/call/linux.c
index e8e0311..36572e9 100644
--- a/tools/libs/call/linux.c
+++ b/tools/libs/call/linux.c
@@ -39,7 +39,7 @@ int osdep_xencall_open(xencall_handle *xcall)
  */
 fd = open("/dev/xen/privcmd", O_RDWR|O_CLOEXEC);
 
-if ( fd == -1 && ( errno == ENOENT || errno == ENXIO || errno == ENODEV ))
+if ( fd == -1 && ( errno == ENOENT || errno == ENXIO || errno == ENODEV || errno == EACCES ))
 {
 /* Fallback to /proc/xen/privcmd */
 fd = open("/proc/xen/privcmd", O_RDWR|O_CLOEXEC);
diff --git a/tools/libs/foreignmemory/linux.c b/tools/libs/foreignmemory/linux.c
index 423c744..72e4b07 100644
--- a/tools/libs/foreignmemory/linux.c
+++ b/tools/libs/foreignmemory/linux.c
@@ -41,7 +41,7 @@ int osdep_xenforeignmemory_open(xenforeignmemory_handle *fmem)
 /* prefer this newer interface */
 fd = open("/dev/xen/privcmd", O_RDWR|O_CLOEXEC);
 
-if ( fd == -1 && ( errno == ENOENT || errno == ENXIO || errno == ENODEV ))
+if ( fd == -1 && ( errno == ENOENT || errno == ENXIO || errno == ENODEV || errno == EACCES ))
 {
 /* Fallback to /proc/xen/privcmd */
 fd = open("/proc/xen/privcmd", O_RDWR|O_CLOEXEC);
-- 
2.1.4

___
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  wrote:
> On Wed, May 17, 2017 at 2:39 AM, George Dunlap  wrote:
>>
>> On Wed, May 17, 2017 at 4:26 AM, Jerry  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] What is the purpose setting console=hvc0 in the dom0 grub config?

[George Dunlap]

On Wed, May 17, 2017 at 4:26 AM, Jerry  wrote:
> Howdy,
>
> I recently went through a frustrating experience trying to get Xen 4 running
> on a CentOS 7 system.  After a fresh install, fully updating the system,
> rebooting, then trying to install Xen4CentOS it would fail to boot into the
> 4.9 kernel, sitting there with a blinking cursor indefinitely.
>
> I thought it was a failure with grub, but it turns out this was set in the
> grub config:
>
> GRUB_CMDLINE_LINUX_XEN_REPLACE_DEFAULT="console=hvc0 ..."
>
> So the kernel was loading successfully, but it was failing boot properly
> (hanging because it couldn't find the / file system, but that's a different
> story). Boot messages were not being displayed on my console because of the
> console=hvc0 setting, hampering the troubleshooting process.
>
> What is the purpose of setting console=hvc0?  I removed it so I could
> trouble shoot this problem, but I didn't re-add it and the system booted
> fine, Xen is working.  Is there something that depends on this?
>
> 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.

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

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).

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

Re: [CentOS-virt] centos-virt IRC meetings

[George Dunlap]

On Tue, May 16, 2017 at 7:21 PM, Sarah Newman  wrote:
> Hi,
>
> We were hoping to attend an IRC meeting this morning but it looks like that 
> didn't happen. Has this been moved to once a month or was this a special week?

Sorry Sarah -- I had a conflict, and since we almost never have guests
the main participants (Sandro, Lokesh, and I) chatted on IRC briefly
and decided to skip it.

Feel free to catch me (gwd) on #centos-devel or #centos-virt if you
want to bring anything up before the next meeting.

 -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  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 
Commit: George Dunlap 

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 
Reviewed-by: Boris Ostrovsky 

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(&pdev->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 needs the platform-pci driver to get
+	 * notifications from L0 Xen, but it cannot use the vecto

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 Mon, Jan 9, 2017 at 7:20 PM, Francis The Metman
 wrote:
> George, Thank you SO much, problem solved using the testing repo.

You're welcome -- thanks for the testing report. :-)

 -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
 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] how to enable auto-start on newer versions of Xen ?

[George Dunlap]

On Mon, Aug 15, 2016 at 8:54 PM, Craig Thompson
 wrote:
> Hello,
>
> In days past, all I had to do was create /etc/xen/auto and put a symlink in
> there to the config file for each VM I wanted to have started automatically.
>
>
> Since updating to 4.6, this doesn't work.  Period.
>
>
> I'm having a hard time finding what needs to change in order to get VMs to
> auto start on reboot of a server.  Can someone please point me to
> documentation that I have missed or share the gold nugget?

Since you're speaking of upgrading, I assume you're using CentOS 6?
What version of the xen packages are you using?

There's a bug in the upstream 4.6 xendomains scripts (which start
things from /etc/xen/auto) when they run on RHEL-based systems.  That
should have been fixed in the xen-4.6.1-9 Virt SIG package.

 -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] Cannot allocate Memory

[George Dunlap]

On Wed, Jun 22, 2016 at 6:45 PM, Shaun Reitan  wrote:
> Any of you guys ever seen an issue with Xen 4.4 were xm cannot create a
> guest because of what looks like an issue allocating memory even though xm
> info shows like 5x the amount of free memory needed? We are still
> unfortunately still using xm... it's on my list, i know..
>
> We've had this happen on a couple hosts now.  Only way to resolve seams to
> be rebooting the host.  I'm going to update the host to latest Xen 4.4 now
> hoping this is a old bug.

xend hasn't had much love in years, so it's fairly unlikely that this
has been fixed.

> Here's from xen logs
>
> [2016-06-22 09:13:50 1958] DEBUG (XendDomainInfo:105)
> XendDomainInfo.create(['vm', ['name', 'xxx'], ['memory', 2048],
> ['on_xend_start', 'ignore'], ['on_xend_stop', 'ignore'], ['vcpus', 2],
> ['oos', 1], ['image', ['linux', ['kernel', '/kernels/vmlinux-2.6.18.8-4'],
> ['videoram', 4], ['args', 'root=/dev/xvda ro xencons=tty console=tty1 '],
> ['tsc_mode', 0], ['nomigrate', 0]]], ['s3_integrity', 1], ['device', ['vbd',
> ['uname', 'phy:vg/fs_6818'], ['dev', 'xvda'], ['mode', 'w']]], ['device',
> ['vbd', ['uname', 'phy:vg/fs_6819'], ['dev', 'xvdb'], ['mode', 'w']]],
> ['device', ['vif', ['rate', '40mb/s'], ['mac', 'FE:FD:48:01:F1:E7')
> [2016-06-22 09:13:50 1958] DEBUG (XendDomainInfo:2504)
> XendDomainInfo.constructDomain
> [2016-06-22 09:13:50 1958] DEBUG (balloon:187) Balloon: 7602632 KiB free;
> need 16384; done.
> [2016-06-22 09:13:50 1958] ERROR (XendDomainInfo:2566) (12, 'Cannot allocate
> memory')
> Traceback (most recent call last):
>   File "/usr/lib64/python2.6/site-packages/xen/xend/XendDomainInfo.py", line
> 2561, in _constructDomain
> target = self.info.target())
> Error: (12, 'Cannot allocate memory')
> [2016-06-22 09:13:50 1958] ERROR (XendDomainInfo:490) VM start failed
> Traceback (most recent call last):
>   File "/usr/lib64/python2.6/site-packages/xen/xend/XendDomainInfo.py", line
> 475, in start
> XendTask.log_progress(0, 30, self._constructDomain)
>   File "/usr/lib64/python2.6/site-packages/xen/xend/XendTask.py", line 209,
> in log_progress
> retval = func(*args, **kwds)
>   File "/usr/lib64/python2.6/site-packages/xen/xend/XendDomainInfo.py", line
> 2572, in _constructDomain
> raise VmError(failmsg)
> VmError: Creating domain failed: name=xxx
> [2016-06-22 09:13:50 1958] ERROR (XendDomainInfo:110) Domain construction
> failed
> Traceback (most recent call last):
>   File "/usr/lib64/python2.6/site-packages/xen/xend/XendDomainInfo.py", line
> 108, in create
> vm.start()
>   File "/usr/lib64/python2.6/site-packages/xen/xend/XendDomainInfo.py", line
> 475, in start
> XendTask.log_progress(0, 30, self._constructDomain)
>   File "/usr/lib64/python2.6/site-packages/xen/xend/XendTask.py", line 209,
> in log_progress
> retval = func(*args, **kwds)
>   File "/usr/lib64/python2.6/site-packages/xen/xend/XendDomainInfo.py", line
> 2572, in _constructDomain
> raise VmError(failmsg)
> VmError: Creating domain failed: name=xxx

If you haven't decided to switch to xl, would you mind reposting this
question to xen-users?  If you do, please also include the output of
"xl info" after the failure.

The logs tell us that xend is asking dom0 to free up some memory to
use to create the guest.  My guess is that there's a slight mismatch
between how much memory xend things needs to be freed and how much
memory actually needs freeing.

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 11:49 AM, Francis Greaves  wrote:
> More information...
> I have pcifront showing as a module in the DomU and the usb shows in dmesg
> as:
> [3.167543] usbcore: registered new interface driver usbfs
> [3.167563] usbcore: registered new interface driver hub
> [3.167585] usbcore: registered new device driver usb
> [3.196056] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
> [3.196060] usb usb1: New USB device strings: Mfr=3, Product=2,
> SerialNumber=1
> [3.196064] usb usb1: Product: EHCI Host Controller
> [3.196068] usb usb1: Manufacturer: Linux 3.2.0-4-686-pae ehci_hcd
> [3.196071] usb usb1: SerialNumber: :00:00.0
> [3.508036] usb 1-1: new high-speed USB device number 2 using ehci_hcd
> [   19.064072] usb 1-1: device not accepting address 2, error -110
> [   19.176070] usb 1-1: new high-speed USB device number 3 using ehci_hcd
> [   34.732067] usb 1-1: device not accepting address 3, error -110
> [   34.844082] usb 1-1: new high-speed USB device number 4 using ehci_hcd
> [   45.280073] usb 1-1: device not accepting address 4, error -110
> [   45.392067] usb 1-1: new high-speed USB device number 5 using ehci_hcd
> [   55.824112] usb 1-1: device not accepting address 5, error -110

Can you post your question with your guest config file, lspci in dom0,
and lspci in your domU to xen-users?  There will be a lot more
eyeballs there to help you get things sorted out.

> I am looking at xl dmesg in Dom0 where there are some messages relating to
> the PCI usb:
> [VT-D] It's disallowed to assign :00:1a.0 with shared RMRR at 7b80
> for Dom6.
> (XEN) XEN_DOMCTL_assign_device: assign :00:1a.0 to dom6 failed (-1)
> (XEN) [VT-D] It's risky to assign :00:1a.0 with shared RMRR at 7b80
> for Dom7.
> (XEN) [VT-D] It's risky to assign :00:1a.0 with shared RMRR at 7b80
> for Dom8.
> (XEN) [VT-D] It's risky to assign :00:1a.0 with shared RMRR at 7b80
> for Dom9.
> (XEN) [VT-D] It's risky to assign :00:1a.0 with shared RMRR at 7b80
> for Dom10.

This looks like you tried once to start your guest without
"rdm_policy=relaxed" (which failed), and then tried it four times with
"rdm_policy=relaxed" (which succeeded).  Other than warning that
there's a shared RMRR (which could potentially be a security risk),
everything here looks normal.

There's a possibility that the shared RMRR is what's tripping things
up, but it's not very likely.

> In the
> as an aside... I just get blocks on the screen after the scrubbing message,
> and no text. I see there is a message:
> (XEN) Xen is relinquishing VGA console.
> How can I prevent this? Is there something wrong with my /etc/default/grub
>
> ...
> GRUB_CMDLINE_LINUX="crashkernel=auto intremap=no_x2apic_optout"
> GRUB_CMDLINE_XEN_DEFAULT="dom0_mem=13312M,max:14336M dom0_max_vcpus=6
> dom0_vcpus_pin"
> GRUB_GFXMODE=1024x768
> GRUB_GFXPAYLOAD_LINUX=keep
> GRUB_CMDLINE_LINUX_XEN_REPLACE_DEFAULT="console=hvc0 earlyprintk=xen"

Could you post this as a separate message to xen-users?

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  wrote:
> On Mon, Jun 13, 2016 at 6:39 AM, George Dunlap  wrote:
>> 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).
>
> 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  wrote:
> On Tue, May 24, 2016 at 3:23 PM, George Dunlap  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

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

[George Dunlap]

On Mon, Apr 11, 2016 at 6:06 PM, exvito here  wrote:
> George,
>
> Thanks a lot for your investigation and feedback.
> I confirm it works as expected after the change you proposed.

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.

 -George
___
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] PCI Passthrough not working

[George Dunlap]

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

(Please reply in-line, like this, rather than top-posting.)

Thanks -- as I suspected, your USB device has RMRRs, which are what's
causing the problem.

In this case, your USB controller's RMRRs are shared with another
device.  Theoretically, having two devices with the same RMRRs
assigned to different domains could be a security issue, so Xen by
default refuses to do it.

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']

Let me know if that works for you.

 -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] XSA-174 kernel updates available in centos-virt-testing

[George Dunlap]

kernel-3.18.25-20, with a fix for XSA-174, has been built in the cbs
and is making its way through the system.  It should be in
centos-virt-xen-testing for both CentOS 6 and CentOS 7 shortly, and a
signed version should be in mirrors after tomorrow's signing run.

(This should be suitable for either people using Xen 4.6 or Xen 4.4.)

Please test it and report any errors here.

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

Re: [CentOS-virt] Problems with scsi-target-utils when hosted on dom0 centos 7 xen box

[George Dunlap]

On Wed, Apr 13, 2016 at 1:18 AM, Nathan Coulson  wrote:
> On 2016-04-12 09:43 AM, Nathan Coulson wrote:
>>
>> By natively, I take it using
>> kernel /vmlinuz (vs kernel /xen)
>>
>> Not yet, but working on setting up such an environment.
>>
>> (At this time, I was using virt-install to reproduce the problem, and the
>> original server we are testing on did not support kvm but the 2nd server
>> does).
>>
>> On 2016-04-12 03:26 AM, George Dunlap wrote:
>>>
>>> On Mon, Apr 11, 2016 at 9:14 PM, Nathan Coulson 
>>> wrote:
>>>>
>>>> Hello
>>>>
>>>> We were attempting to use scsi-target-utils, hosted on a xen dom0 vm
>>>> using
>>>> localhost, and running into some problems.  I was not able to reproduce
>>>> this
>>>> on a centos 7.2 server using the default kernel.
>>>
>>> Have you tried booting the Virt SIG kernel natively and seeing if you
>>> can reproduce the problem at all?
>>>
>>> Thanks,
>>>   -George
>
>
>
> (Apologies for the earlier top post)
>
> Running the kernel natively, on 3.10 or 3.18 (kernel from virt sig)
> * CentOS Linux (3.18.25-19.el7.x86_64) 7 (Core))
> * CentOS Linux (3.10.0-327.13.1.el7.x86_64) 7 (Core)
>
> It works as expected with no issues.
>
>
>
> But when booting as dom0 using the xen hypervisor
> * CentOS Linux, with Xen hypervisor
>
> tested with dom0_mem=2048M,max:2048M (as well as 1024M)
>
> the problems occur as I have describe.

Thanks Nathan.  It looks then like this may be an issue with upstream
Xen, then.  Would you be willing to re-post this bug report (with the
information that it works running the same kernel on native) to
xen-users?  I can make sure it's seen by the appropriate kernel-side
developers if necessary.

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

Re: [CentOS-virt] Problems with scsi-target-utils when hosted on dom0 centos 7 xen box

[George Dunlap]

On Mon, Apr 11, 2016 at 9:14 PM, Nathan Coulson  wrote:
> Hello
>
> We were attempting to use scsi-target-utils, hosted on a xen dom0 vm using
> localhost, and running into some problems.  I was not able to reproduce this
> on a centos 7.2 server using the default kernel.

Have you tried booting the Virt SIG kernel natively and seeing if you
can reproduce the problem at all?

Thanks,
 -George

>
>
> (From dmesg)
> Apr  4 11:18:42 funk kernel: [  596.511204]  connection2:0: detected conn
> error (1022)
> Apr  4 11:18:42 funk kernel: connection2:0: ping timeout of 5 secs expired,
> recv timeout 5, last rx 4295253788, last ping 4295258790, now 4295263808
> Apr  4 11:18:42 funk kernel: connection2:0: detected conn error (1022)
> Apr  4 11:18:42 funk iscsid: Kernel reported iSCSI connection 2:0 error
> (1022 - Invalid or unknown error code) state (3)
> Apr  4 11:18:44 funk iscsid: connection2:0 is operational after recovery (1
> attempts)
>
> Repeated a few times, until eventually
>
>
> Apr  4 11:19:44 funk kernel: Result: hostbyte=DID_TRANSPORT_DISRUPTED
> driverbyte=DRIVER_OK
> Apr  4 11:19:44 funk kernel: sd 7:0:0:1: [sdd] CDB:
> Apr  4 11:19:44 funk kernel: Write(10): 2a 00 01 df c7 e8 00 00 18 00
> Apr  4 11:19:44 funk kernel: blk_update_request: I/O error, dev sdd, sector
> 31442920
> Apr  4 11:19:44 funk kernel: [  658.127596] sd 7:0:0:1: [sdd]
> Apr  4 11:19:44 funk kernel: [  658.127688] Result:
> hostbyte=DID_TRANSPORT_DISRUPTED driverbyte=DRIVER_OK
> Apr  4 11:19:44 funk kernel: [  658.127761] sd 7:0:0:1: [sdd] CDB:
> Apr  4 11:19:44 funk kernel: [  658.127826] Write(10): 2a 00 01 df c7 e8 00
> 00 18 00
> Apr  4 11:19:44 funk kernel: [  658.127927] blk_update_request: I/O error,
> dev sdd, sector 31442920
> Apr  4 11:19:44 funk kernel: [  658.128040] sd 7:0:0:1: [sdd]
> Apr  4 11:19:44 funk kernel: sd 7:0:0:1: [sdd]
> Apr  4 11:19:44 funk kernel: [  658.128105] Result:
> hostbyte=DID_TRANSPORT_DISRUPTED driverbyte=DRIVER_OK
> Apr  4 11:19:44 funk kernel: [  658.128177] sd 7:0:0:1: [sdd] CDB:
> Apr  4 11:19:44 funk kernel: [  658.128241] Write(10): 2a 00 00 00 08 00 00
> 00 18 00
> Apr  4 11:19:44 funk kernel: [  658.128339] blk_update_request: I/O error,
> dev sdd, sector 2048
> Apr  4 11:19:44 funk kernel: Result: hostbyte=DID_TRANSPORT_DISRUPTED
> driverbyte=DRIVER_OK
> Apr  4 11:19:44 funk kernel: sd 7:0:0:1: [sdd] CDB:
> Apr  4 11:19:44 funk kernel: Write(10): 2a 00 00 00 08 00 00 00 18 00
> Apr  4 11:19:44 funk kernel: blk_update_request: I/O error, dev sdd, sector
> 2048
>
>
> (Test Setup)
> scsi-target-utils installed via yum, default config
> /etc/tgt/conf.d/xenguests.conf
> 
> backing-store //mnt/vmdisk/test # vm image
> 
>
> systemctl tgtd restart
>
> iscsiadm -m discovery -t sendtargets -p localhost
>
> iscsiadm -m node -T iqn.2016-02.com.bravenet:test -l
>
>
> add it to lvm (pvcreate, vgcreate), let's call it /dev/vmdisk.vg/test.lv
>
> and then use libvirt to attempt to install an os on /dev/vmdisk.vg/test.lv
> (using anaconda)
>
>
>
>
> Around the time it tries to create the disk label, is when the conn errors
> start, until eventually it gives up trying to create the disk label.
>
>
>
> We tested a similar setup on a centos 7.2 host we use kvm based
> virtualmachine hosting on (default 3.10 kernel), and it worked fine.  It may
> be similar to what was reported on
> https://bugzilla.redhat.com/show_bug.cgi?id=1245990, but I never saw a
> resolution on what they discovered (other then a reference to comment18
> which does not appear to exist).
>
> Testing over the network appears to also work as well (where another machine
> connects to scsi-target-utils on the funk server above.
>
>
>
>
>
> Longterm Purpose of the above setup, was to get direct access to a
> filesystem image hosted on a gluster setup, using bs-type glfs on
> scsi-target-utils.
>
> --
> Nathan Coulson
> www.bravenet.com
> nat...@bravenet.com
> ___
> 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] Xen4CentOS 6 64bit - domUs don't shutdown on dom0 after "yum upgrade" to 4.6.1

[George Dunlap]

On Thu, Apr 7, 2016 at 5:46 PM, exvito here  wrote:
> Hello all,
>
> I'm addressing the mailing list following the suggestion of gwd on
> #centos-virt @freenode IRC.
>
> The subject says most of it. Here are the details :
>
> - Was running 4.4.x and configured such that /etc/xen/auto domUs would be
> saved/restored on dom0 shutdown/bootup.
> - Installation was based on "centos-release-xen" such that "yum upgrade"
> brough Xen to 4.6.1.
>
> After upgrade observed behavior:
> - dom0 boot starts up the domUs in /etc/xen/auto.
> - dom0 shutdown does not save/shutdown domUs (the command is "shutdown -h
> now" via ssh).
>
> Diagnostics:
> - Running /etc/init.d/xendomains stop/start does the right thing.
> - chkconfig --list shows "xendomains 0:off 1:off 2:on 3:on 4:on 5:on
> 6:off" which looks nice.
> - The rc link is in place: /etc/rc.d/rc0.d/K00xendomains ->
> ../init.d/xendomains
> - Edited /etc/init.d/xendomains such that the lines:
>
> start)
> $LIBEXEC_BIN/xendomains start
> ;;
> stop)
> $LIBEXEC_BIN/xendomains stop
> ;;
>
> become (added "2>&1 | tee FILE" to the underlying start/stop command)
>
> start)
> $LIBEXEC_BIN/xendomains start 2>&1 | /usr/bin/tee -a
> /tmp/xd-start.log
> ;;
> stop)
> $LIBEXEC_BIN/xendomains stop 2>&1 | /usr/bin/tee -a /tmp/xd-stop.log
> ;;
>
> - The /tmp/xd-stop.log file is not created on dom0 shutdown (make sense, but
> why?!).
> - The /tmp/xd-stop.log is created on dom0 boot, as expected.
> - Both files are created on manual /etc/init.d/xendomains start/stop
> - Manually added an rc link: /etc/rc.d/rc0.d/K01xendomains ->
> ../init.d/xendomains
> - The behavior remains unchanged.
>
> This is looking much more of an upstart/sysvinit issue that a Xen 4.6 issue.
> However, I believe others may have been through this experience.
>
> Can anyone provide any pointers in further diagnosing this?
> Thanks in advance.

Hey exvito,

I finally got a chance to look at this.  It turns out that one of the
paths was incorrectly changed between 4.4 and 4.6.

To fix your problem, after upgrading to 4.6, please edit the following file:

/etc/xen/scripts/hotplugpath.sh

and replace

XEN_LOCK_DIR="/var/lock"

with

XEN_LOCK_DIR="/var/lock/subsys"

I'll be working on a proper fix with upstream -- I'll post here when
I've got packages with the backported change to test.

What's happening is that the CentOS init scripts only shut down
services that indicate they have an active component running -- which
it takes to mean, "Has a lockfile in /var/lock/subsys".  As you can
probably guess, in 4.6 the lockfile is being created in /var/lock
instead; so when shutting down, "xendomains stop" was never called.

The /var/lock/subsys thing is apparently a RHEL thing; other systems
seem to call "${service} stop" unconditionally.

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

Re: [CentOS-virt] CentOS7, Xen 4.6.1, kernel 3.18.25-19 strange performance problem

[George Dunlap]

On Sun, Apr 10, 2016 at 11:20 AM, T.Weyergraf  wrote:
> Hi all,
>
> i just stumbled over a strange performance issue with my Xen setup.
>
> I use centos-virt Xen since a long time on my workstation and usually never
> check performance. However, yesterday I booted into the 3.18.25-19 Dom0
> kernel *without* Xen and found the system noticably more responsive. That
> triggered me into running a simple kernel compile benchmark and compare the
> results:

Thanks for the report.  64-bit PV is known to be slow for Xen for
workloads that involve a lot of system calls (which kernel build
certainly will).  You can read an explanation for the issue, and our
intended solution, in this blog post I wrote a few years ago:

https://blog.xenproject.org/2012/10/31/the-paravirtualization-spectrum-part-2-from-poles-to-a-spectrum/

Unfortunately the initial implementation of PVH turned out to have
some technical issues, and it's in the process of being revamped.  The
work is actively ongoing, but it's likely to be another year at least
before we're going to be able to default to a PVH dom0 kernel for
CentOS.

Still, over 3x for a kernel build is rather surprising -- I'll ask
around and see what other people's expectations / experiences are.
It's possible there's a regression in the CentOS build that hasn't
been noticed.  In particular, if you happen to find any other
combination of Xen / kernel which is significantly faster, do report
it so we can look into it.

 -George
___
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  wrote:
> On 23/02/16 15:04, George Dunlap wrote:
>> On Sat, Feb 20, 2016 at 9:24 PM, Sarah Newman  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  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

[CentOS-virt] Reminder: Virt SIG meeting today at 1500 UTC (note changed time)

[George Dunlap]

Just a reminder, we'll be having the regular Virt SIG meeting today at
the new time -- 1500 UTC.

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

Re: [CentOS-virt] Garbled screen after RAM Scrub on boot

[George Dunlap]

On Mon, Feb 22, 2016 at 4:18 PM, Francis Greaves  wrote:
> Dear All
> I am using Centos 7 with Xen 4.6 on a Dell Poweredge T430
> When the machine boots, after the 'Scrubbing Free RAM' message, I get a
> screen filled with little white squares until the login prompt, so I cannot
> see what is happening as the machine boots. Also there is nothing on the
> screen when I reboot.
>
> My /etc/default/grub is
>
> GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
> GRUB_DEFAULT=saved
> GRUB_DISABLE_SUBMENU=true
> GRUB_CMDLINE_LINUX="crashkernel=auto rhgb intremap=no_x2apic_optout"
> GRUB_CMDLINE_XEN_DEFAULT="dom0_mem=13312M,max:14336M dom0_max_vcpus=6
> dom0_vcpus_pin"
> GRUB_GFXMODE=1024x768
> GRUB_GFXPAYLOAD_LINUX=keep
> GRUB_CMDLINE_LINUX_XEN_REPLACE_DEFAULT="console=hvc0 earlyprintk=xen
> nomodeset"
>
> I have tried setting (for a 1024x768 resolution) vga=792 in the
> GRUB_CMDLINE_LINUX and commenting out GRUB_GFXMODE and
> GRUB_GFXPAYLOAD_LINUX, but this makes no difference
>
> What am I doing wrong?

Francis,

Thanks for reporting this.  I'd suggest re-posting your question on
xen-users -- there are a lot more eyeballs watching that list than
this one, and it's easier to "escalate" the issue to the development
list from there.

My first instinct is wondering whether grub setting the graphics mode
is part of the problem.  Have you tried having grub just take the bios
text mode that was given it, rather than changing it?

(Obviously ideally Xen would work whatever the graphics mode is, but
most developers are accessing test boxes over serial in a colo, so
it's not the kind of thing they're prone to notice.)

 -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  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  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 specific

[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  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

[CentOS-virt] Centos 7 Xen Release!

[George Dunlap]

I am pleased to announce the official release of Virt SIG Xen packages
for CentOS 7.

To install:

* 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 repo:

yum install xen

There are also packages for libvirt 1.3.0 (which should be compatible
with openstack) and virt-manager.

Please report any bugs you find in the packaging here.

 -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
 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 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] 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 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 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 12:01 PM, Peter  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] DomU Guests not shutting down nicely when Dom0 Hypervisor shuts down

[George Dunlap]

On Thu, Jan 21, 2016 at 9:20 AM, Phill Bandelow  wrote:
> Try this:
>
> systemctl start xendomains.service
> systemctl enable xendomains.service

Yes, the main difference between C6 and C7 from Xen's perspective is
switching from the sysv initscripts to systemd.

It's probably worth enabling xendomains by default, particularly if
they were enabled by default in C6.  I'll put that on my list to do at
some point (unless someone wants to implement it and send me a pull
request).

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

[CentOS-virt] Updated centos-release-xen packages (fixes missing initrd issue on upgrade)

[George Dunlap]

I've pushed an update to the centos-release-xen package,
centos-release-xen-7-12.el6, to centos-virt-xen-testing, which should
fix the "missing initrd" issue people have been seeing.

Please test and see if it fixes your issue (and that it makes no other
issues).  If everything works well, I'll get it pushed to
centos-extras.

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