At long last, I'd like to announce beta packages for CentOS 7, available from the community build system.
Start by installing the centos-release-xen:
rpm -ivh http://cbs.centos.org/repos/virt7-xen-44-testing/x86_64/os/Packages/centos-r...
This will set up yum repositories for both the eventual release repositories (enabled by default), and the community build system repositories (disabled by default).
At the moment, all packages will be stored in the virt-xen-44-testing repository. You can either enable this by default by editing /etc/yum.repos.d/VirtSIG-Xen.repo, or by adding "--enablerepo=virt-xen-44-testing".
If you want, you can edit defaults /etc/sysconfig/xen-kernel
Next, run 'yum update' to get the new kernel:
yum --enablerepo=virt-xen-44-testing update kernel
Now install xen:
yum --enablerepo=virt-xen-44-testing install xen
This should grab both xen and the updated kernel package. It should also automatically: * Add default commandline parameters for Xen and Linux when booting under Xen * Arrange for xen to come up first in the grub * Set the default boot entry to Xen.
That's it! Reboot and you should be good to go.
Libvirt packages aren't available yet but should be on the way soon (I'll announce them here.)
Please report any problems or feedback to this list.
-George
On Wed, Jun 17, 2015 at 03:24:45PM +0100, George Dunlap wrote:
At long last, I'd like to announce beta packages for CentOS 7, available from the community build system.
Start by installing the centos-release-xen:
rpm -ivh http://cbs.centos.org/repos/virt7-xen-44-testing/x86_64/os/Packages/centos-r...
This will set up yum repositories for both the eventual release repositories (enabled by default), and the community build system repositories (disabled by default).
At the moment, all packages will be stored in the virt-xen-44-testing repository. You can either enable this by default by editing /etc/yum.repos.d/VirtSIG-Xen.repo, or by adding "--enablerepo=virt-xen-44-testing".
If you want, you can edit defaults /etc/sysconfig/xen-kernel
Next, run 'yum update' to get the new kernel:
yum --enablerepo=virt-xen-44-testing update kernel
Now install xen:
yum --enablerepo=virt-xen-44-testing install xen
This should grab both xen and the updated kernel package. It should also automatically:
- Add default commandline parameters for Xen and Linux when booting under Xen
- Arrange for xen to come up first in the grub
- Set the default boot entry to Xen.
That's it! Reboot and you should be good to go.
Libvirt packages aren't available yet but should be on the way soon (I'll announce them here.)
Please report any problems or feedback to this list.
Good stuff! I'll test these packages soon.
Thanks a lot.
-- Pasi
-George
On 06/17/2015 04:24 PM, George Dunlap wrote:
At long last, I'd like to announce beta packages for CentOS 7, available from the community build system.
Great to see Xen coming to CentOS 7 !
I gave the virtx7-44-testing packages a spin on a fresh CentOS 7 install (legacy boot, no efi, as there is no xen.efi). However, I was not able to start any HVM or PVHVM guests. Upon create, the DomU was setup but did not do anything, but instead entered a reboot-loop (Dom ID was increased, but no boot output. No bootloader output on the console, despite everything in the guest setup to display on serial console). The exact same guests worked fine with Xen4CentOS xen+kernel packages for CentOS6. Note, that PV DomUs run fine (tested with CentOS5).
I did not invest too much time into debugging, but from xl's logs, the DomU was apparently shutdown upon creation:
Waiting for domain xencen7 (domid 1) to die [pid 3162] Domain 1 has shut down, reason code 1 0x1 Action for shutdown reason code 1 is restart Domain 1 needs to be cleaned up: destroying the domain Done. Rebooting now Waiting for domain xencen7 (domid 2) to die [pid 3162] Domain 2 has shut down, reason code 1 0x1 Action for shutdown reason code 1 is restart Domain 2 needs to be cleaned up: destroying the domain Done. Rebooting now ....
The interesting part is, that the pid of the xl create job (3162) remains the same, thus xl create never exits but instead attempt the re-create the DomU in a loop, only to be stopped by killing the xl process.
At the moment, I run my own self-build CentOS 7 xen packages. But if desired, I can switch back to the virt7-xen-44-testing packages to assist any debugging.
Regards, Thomas
Hi Thomas,
This may be old news at this point, but I had 100% identical behavior to yours when I tried virtx7-44-testing. After looking around a bit I tried "virtx7-44-candidate", in a sibling directory to virtx7-44-testing. It has a more recent date, so I tried with that and it works fine. It resolves the issues listed in your email from 7/7/2015.
I am now looking for a libvirt-daemon-xen package for Centos 7. Any ideas on where that lives?
Thanks, Chuck
----- Original Message -----
From: "Chuck Meade" chuckmeade@gmail.com To: centos-virt@centos.org Sent: Thursday, September 3, 2015 12:50:55 PM Subject: Re: [CentOS-virt] Beta CentOS 7 Xen packages available
Hi Thomas,
This may be old news at this point, but I had 100% identical behavior to yours when I tried virtx7-44-testing. After looking around a bit I tried "virtx7-44-candidate", in a sibling directory to virtx7-44-testing. It has a more recent date, so I tried with that and it works fine. It resolves the issues listed in your email from 7/7/2015.
I am now looking for a libvirt-daemon-xen package for Centos 7. Any ideas on where that lives?
Chuck, that's a subpackage of libvirt. Look in these:
http://cbs.centos.org/koji/packageinfo?packageID=130
Jason
Thanks, Chuck _______________________________________________ CentOS-virt mailing list CentOS-virt@centos.org https://lists.centos.org/mailman/listinfo/centos-virt
Thanks Jason, I had accidentally left off the "--enablerepo=virt-xen-44-candidate" from the yum install command.
Chuck
On 09/03/2015 03:58 PM, Jason Brooks wrote:
----- Original Message -----
From: "Chuck Meade" chuckmeade@gmail.com To: centos-virt@centos.org Sent: Thursday, September 3, 2015 12:50:55 PM Subject: Re: [CentOS-virt] Beta CentOS 7 Xen packages available
Hi Thomas,
This may be old news at this point, but I had 100% identical behavior to yours when I tried virtx7-44-testing. After looking around a bit I tried "virtx7-44-candidate", in a sibling directory to virtx7-44-testing. It has a more recent date, so I tried with that and it works fine. It resolves the issues listed in your email from 7/7/2015.
I am now looking for a libvirt-daemon-xen package for Centos 7. Any ideas on where that lives?
Chuck, that's a subpackage of libvirt. Look in these:
http://cbs.centos.org/koji/packageinfo?packageID=130
Jason
Thanks, Chuck _______________________________________________ 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
On 09/03/2015 09:50 PM, Chuck Meade wrote:
Hi Thomas,
Hi Chuck
This may be old news at this point, but I had 100% identical behavior to yours when I tried virtx7-44-testing. After looking around a bit I tried "virtx7-44-candidate", in a sibling directory to virtx7-44-testing. It has a more recent date, so I tried with that and it works fine. It resolves the issues listed in your email from 7/7/2015.
Thanks for letting me know. I actually found the "candiate" packages to work too, when tried those some days after my email. However, nowadays I build my own Xen rpm's, based on the Fedora 21 source package. I modified the spec-file to properly build for CentOS 7 and adapted some of the patches of the Fedora source package.
To me, the advantage is proper systemd intergration. It has systemd unit files for all xen-related services. Likewise, I keep the version up to date to my taste, like running 4.4.3. My xen-packages work well for me and if anybody is interested, I can polish things up a bit, setup a repo and make them accessible.
I am now looking for a libvirt-daemon-xen package for Centos 7. Any ideas on where that lives?
That question has already been answered in this thread.
Thanks, Chuck _______________________________________________ CentOS-virt mailing list CentOS-virt@centos.org https://lists.centos.org/mailman/listinfo/centos-virt
Regards, Thomas
On 09/04/2015 05:39 PM, T.Weyergraf wrote:
On 09/03/2015 09:50 PM, Chuck Meade wrote:
Hi Thomas,
Hi Chuck
This may be old news at this point, but I had 100% identical behavior to yours when I tried virtx7-44-testing. After looking around a bit I tried "virtx7-44-candidate", in a sibling directory to virtx7-44-testing. It has a more recent date, so I tried with that and it works fine. It resolves the issues listed in your email from 7/7/2015.
Thanks for letting me know. I actually found the "candiate" packages to work too, when tried those some days after my email. However, nowadays I build my own Xen rpm's, based on the Fedora 21 source package. I modified the spec-file to properly build for CentOS 7 and adapted some of the patches of the Fedora source package.
To me, the advantage is proper systemd intergration. It has systemd unit files for all xen-related services. Likewise, I keep the version up to date to my taste, like running 4.4.3. My xen-packages work well for me and if anybody is interested, I can polish things up a bit, setup a repo and make them accessible.
Thanks Thomas, I really appreciate the feedback.
Best regards, Chuck
I am now looking for a libvirt-daemon-xen package for Centos 7. Any ideas on where that lives?
That question has already been answered in this thread.
Thanks, Chuck _______________________________________________ CentOS-virt mailing list CentOS-virt@centos.org https://lists.centos.org/mailman/listinfo/centos-virt
Regards, Thomas _______________________________________________ CentOS-virt mailing list CentOS-virt@centos.org https://lists.centos.org/mailman/listinfo/centos-virt
On 09/04/2015 04:39 PM, T.Weyergraf wrote:
On 09/03/2015 09:50 PM, Chuck Meade wrote:
Hi Thomas,
Hi Chuck
This may be old news at this point, but I had 100% identical behavior to yours when I tried virtx7-44-testing. After looking around a bit I tried "virtx7-44-candidate", in a sibling directory to virtx7-44-testing. It has a more recent date, so I tried with that and it works fine. It resolves the issues listed in your email from 7/7/2015.
Thanks for letting me know. I actually found the "candiate" packages to work too, when tried those some days after my email. However, nowadays I build my own Xen rpm's, based on the Fedora 21 source package. I modified the spec-file to properly build for CentOS 7 and adapted some of the patches of the Fedora source package.
To me, the advantage is proper systemd intergration. It has systemd unit files for all xen-related services. Likewise, I keep the version up to date to my taste, like running 4.4.3. My xen-packages work well for me and if anybody is interested, I can polish things up a bit, setup a repo and make them accessible.
What we really need is to make the REAL xen RPMs .. the ones produced in this SIG .. work with systemd. These RPMs are produced by Citrix, so we need to get the right.
So, what works and what does not work (ie, no systemd integration problem) needs to be addressed.
We don't want to create forked repos, IMHO.
On 09/07/2015 12:40 PM, Johnny Hughes wrote:
On 09/04/2015 04:39 PM, T.Weyergraf wrote:
On 09/03/2015 09:50 PM, Chuck Meade wrote:
Hi Thomas,
Hi Chuck
This may be old news at this point, but I had 100% identical behavior to yours when I tried virtx7-44-testing. After looking around a bit I tried "virtx7-44-candidate", in a sibling directory to virtx7-44-testing. It has a more recent date, so I tried with that and it works fine. It resolves the issues listed in your email from 7/7/2015.
Thanks for letting me know. I actually found the "candiate" packages to work too, when tried those some days after my email. However, nowadays I build my own Xen rpm's, based on the Fedora 21 source package. I modified the spec-file to properly build for CentOS 7 and adapted some of the patches of the Fedora source package.
To me, the advantage is proper systemd intergration. It has systemd unit files for all xen-related services. Likewise, I keep the version up to date to my taste, like running 4.4.3. My xen-packages work well for me and if anybody is interested, I can polish things up a bit, setup a repo and make them accessible.
What we really need is to make the REAL xen RPMs .. the ones produced in this SIG .. work with systemd. These RPMs are produced by Citrix, so we need to get the right.
So, what works and what does not work (ie, no systemd integration problem) needs to be addressed.
We don't want to create forked repos, IMHO.
First of all, I fully agree, that forked repos are undesirable. However, to the casual observer (like me), there are hardly any ressources for Xen on CentOS 7. There are some beta packages, as announced in the start if this thread, with the latest update being 4.4.2 on 4th of august. I have not yet found any git repo to check out the current Xen 4 CentOS 7 development effort - only the source rpms to the above packages could be used. Likewise, the response on the list on the announcements of the Xen on CentOS 7 beta packages was kind of mute and no further updates were given. This led me to the - apparently false - assumption, that the project kind of fell asleep. I'd be more than happy to at least test development packages and give feedback.
Your statement "These RPMs are produced by Citrix, so we need to get the right" irritates me, as I was completely unaware of any "rights" from Citrix to be waited for.
Anyway, I will wait for the official Xen4CentOS packages for CentOS 7 and keep my stuff out of the public to avoid useless forks.
On Mon, Sep 7, 2015 at 11:02 PM, T.Weyergraf T.Weyergraf@virtfinity.de wrote:
First of all, I fully agree, that forked repos are undesirable. However, to the casual observer (like me), there are hardly any ressources for Xen on CentOS 7. There are some beta packages, as announced in the start if this thread, with the latest update being 4.4.2 on 4th of august. I have not yet found any git repo to check out the current Xen 4 CentOS 7 development effort - only the source rpms to the above packages could be used. Likewise, the response on the list on the announcements of the Xen on CentOS 7 beta packages was kind of mute and no further updates were given. This led me to the - apparently false - assumption, that the project kind of fell asleep. I'd be more than happy to at least test development packages and give feedback.
Your statement "These RPMs are produced by Citrix, so we need to get the right" irritates me, as I was completely unaware of any "rights" from Citrix to be waited for.
Anyway, I will wait for the official Xen4CentOS packages for CentOS 7 and keep my stuff out of the public to avoid useless forks.
So actually, the SIGs are supposed to be community efforts -- and my long term hope was that once the SIG was "jump-started", that community members would step up to take over -- or at least step up to help significantly.
A number of reasons C7 has "stalled":
* Lack of time on my part. I only work 4 days a week for Citrix, and I have significant other duties. Normally I can only spend a day or so a week on CentOS stuff; and in particular, the review load relating to the 4.6 feature freeze (beginning of July) was very high. Then I got married and went on holiday for 3 weeks in August, which also didn't help. :-)
* Apparent lack of testing by the community. About a month after the C7 "beta", I was about to announce an actual release, when I happened to discover that HVM guests wouldn't boot -- not under any configuration. This is really basic core functionality that nobody at all had tested (or if they had they hadn't complained). This convinced me that I couldn't rely on community testing, and prompted me to spend some time writing an automated test suite that would at least do a basic smoke-test for a number of configurations. I've got this working for the core xen package, but I was planning on extending it to libvirt before declaring CentOS 7 "ready".
I'm sorry I haven't been very pro-active about pushing to the xen package repository -- I didn't know anyone was looking. (If you asked about it, then I must have missed it.)
I would be happy to have help improving the packages. I would be *very* happy to have help maintaining the Xen4CentOS packages, and I would be *delighted* if someone wanted to take over maintainership of the packages entirely.
FYI I have just finished rebasing things to 4.6-rc2 (there are packages in virt7-xen-46-candidate now), and am in the process of switching things over to systemd.
The Virt SIG has IRC meetings on freenode channel #centos-devel every two weeks -- the next one is today (8 September) at 2pm BST (3pm UTC). If anyone wants to help contribute / see what the status of Xen4CentOS is, feel free to pop in.
-George
On Tue, 2015-09-08 at 12:02 +0100, George Dunlap wrote:
Then I got married and went on holiday for 3 weeks in August,
Congratulations. Its nicer cuddling a real person rather than a computer.
The Virt SIG has IRC meetings on freenode channel #centos-devel every two weeks -- the next one is today (8 September) at 2pm BST (3pm UTC). If anyone wants to help contribute / see what the status of Xen4CentOS is, feel free to pop in.
BST = British Summer Time = GMT/UTC + 1:00. Thus 14:00 BST = 13:00 UTC.
On Tue, Sep 8, 2015 at 12:12 PM, Always Learning centos@u64.u22.net wrote:
On Tue, 2015-09-08 at 12:02 +0100, George Dunlap wrote:
Then I got married and went on holiday for 3 weeks in August,
Congratulations. Its nicer cuddling a real person rather than a computer.
The Virt SIG has IRC meetings on freenode channel #centos-devel every two weeks -- the next one is today (8 September) at 2pm BST (3pm UTC). If anyone wants to help contribute / see what the status of Xen4CentOS is, feel free to pop in.
BST = British Summer Time = GMT/UTC + 1:00. Thus 14:00 BST = 13:00 UTC.
Oops. :-) Just to confirm, this should be the right time (2pm BST).
-George
On Tue, Sep 8, 2015 at 7:02 AM, George Dunlap dunlapg@umich.edu wrote:
- Apparent lack of testing by the community. About a month after the
C7 "beta", I was about to announce an actual release, when I happened to discover that HVM guests wouldn't boot -- not under any configuration. This is really basic core functionality that nobody at all had tested (or if they had they hadn't complained). This convinced me that I couldn't rely on community testing, and prompted me to spend some time writing an automated test suite that would at least do a basic smoke-test for a number of configurations. I've got this working for the core xen package, but I was planning on extending it to libvirt before declaring CentOS 7 "ready".
A lot of it is market forces. A lot of people who used to run their own VM's have basically given up, and allow AWS or similar services to do it for them. Learning a few command line tools is often a *lot* faster, and cheaper, than running your own virtualization infrastructure. Heck, I *published* the first public RPM's for Xen, way back in 1997 before it was bought by Citrix, and I don't have the time and hardware in hand to do it anymore!
I'm also afraid a lot of us have basically given up on CentOS 7, while the developer community deals with all the multiple OS issues of the systemd reworking of network and init configuration, the-arranged "/bin" versus "/usr/bin" overlap of component locations, and the profound lack of EPEL for CentOS 6 or Fedora published perl and python modules ported to CentOS 7. That's not a CentOS team issue, that's a RHEL issue, but it's profoundly lowering interest in both hypervisors and VM's that are CentOS 7 based.
I would be happy to have help improving the packages. I would be *very* happy to have help maintaining the Xen4CentOS packages, and I would be *delighted* if someone wanted to take over maintainership of the packages entirely.
FYI I have just finished rebasing things to 4.6-rc2 (there are packages in virt7-xen-46-candidate now), and am in the process of switching things over to systemd.
And that is one of the parts that is sucking away testing time on a lot of open source or freeware projects. The systemd integration of init scripts, networking tools, and the /bin symlink to /usr/bin have been breaking a *lot* of previously stable components. A lot of us are basically giving CentOS 7 a miss until and unless the rest of the stable server community can catch up with the environment changes.
On 09/08/2015 01:02 PM, George Dunlap wrote:
On Mon, Sep 7, 2015 at 11:02 PM, T.Weyergraf T.Weyergraf@virtfinity.de wrote:
First of all, I fully agree, that forked repos are undesirable. However, to the casual observer (like me), there are hardly any ressources for Xen on CentOS 7. There are some beta packages, as announced in the start if this thread, with the latest update being 4.4.2 on 4th of august. I have not yet found any git repo to check out the current Xen 4 CentOS 7 development effort - only the source rpms to the above packages could be used. Likewise, the response on the list on the announcements of the Xen on CentOS 7 beta packages was kind of mute and no further updates were given. This led me to the - apparently false - assumption, that the project kind of fell asleep. I'd be more than happy to at least test development packages and give feedback.
Your statement "These RPMs are produced by Citrix, so we need to get the right" irritates me, as I was completely unaware of any "rights" from Citrix to be waited for.
Anyway, I will wait for the official Xen4CentOS packages for CentOS 7 and keep my stuff out of the public to avoid useless forks.
See my comments inline as appropriate
So actually, the SIGs are supposed to be community efforts -- and my long term hope was that once the SIG was "jump-started", that community members would step up to take over -- or at least step up to help significantly.
Cool. Good to know. Well, while I have been using CentOS for several years now in both private and professional setups, I have to admit, that so far I did not delve into the community itself and make myself familiar with its processes and procedures. It might be time to change that :)
A number of reasons C7 has "stalled":
- Lack of time on my part. I only work 4 days a week for Citrix, and I
have significant other duties. Normally I can only spend a day or so a week on CentOS stuff; and in particular, the review load relating to the 4.6 feature freeze (beginning of July) was very high. Then I got married and went on holiday for 3 weeks in August, which also didn't help. :-)
Well, first of all congrats to your recent marriage! I know what your were up to lately, as I did the same some 6+ years ago. And much like you, I have to dedicate my personal free-time to any effort. On the plus side, I am a sysadmin actually using Xen4CentOS on top of CentOS 6 in a professional production environment, spanning 50 virtualisation hosts and running over 600 VMs (over 1,500 pCPUs over 10Tbytes RAM). So I get pretty much of an impression, what it means to actually use Xen4CentOS.
- Apparent lack of testing by the community. About a month after the
C7 "beta", I was about to announce an actual release, when I happened to discover that HVM guests wouldn't boot -- not under any configuration. This is really basic core functionality that nobody at all had tested (or if they had they hadn't complained). This convinced me that I couldn't rely on community testing, and prompted me to spend some time writing an automated test suite that would at least do a basic smoke-test for a number of configurations. I've got this working for the core xen package, but I was planning on extending it to libvirt before declaring CentOS 7 "ready".
You already found out in another post, that I actually did test the CentOS 7 packages early in july and reported to the list. That lack of any response on my report triggered me to do Xen 4 on CentOS7 packages myself.
I'm sorry I haven't been very pro-active about pushing to the xen package repository -- I didn't know anyone was looking. (If you asked about it, then I must have missed it.)
See above.
I would be happy to have help improving the packages. I would be *very* happy to have help maintaining the Xen4CentOS packages, and I would be *delighted* if someone wanted to take over maintainership of the packages entirely.
Well, I'd be happy to help. I can easily test things out on my private setup, which is all geared towards Xen and virtualisation anyway, so I am all setup. To actually contribute, I would ideally like some git-repo to checkout, to prep patches against. Those patches, I could send to you for review. If there is some process aligned to "the CentOS way of doing things", I would need a pointer to some docs to make myself familiar with. As I have not the faintest clue about what it takes to actually maintain a package, i am - at least now - the inappropriate person.
FYI I have just finished rebasing things to 4.6-rc2 (there are packages in virt7-xen-46-candidate now), and am in the process of switching things over to systemd.
Yeah, saw that yesterday in the repo. Ok then, I will fetch it soon and start testing it in one of my CentOS-7 Xen guests (I run nested-Xen). If that test succeeds, I could update the host. That way, these packages would get some real-world test, running my zoo of guests. Oviously, I'll report my findings. I would propose to see, if that yields anything useful to the development of the Xen4CentOS 7 packages. To actually look into code, I'll fetch the source-packages of that repo.
The Virt SIG has IRC meetings on freenode channel #centos-devel every two weeks -- the next one is today (8 September) at 2pm BST (3pm UTC). If anyone wants to help contribute / see what the status of Xen4CentOS is, feel free to pop in.
I popped in late, close to closure of the meeting. I resorted to readonly, as I wanted to grasp the "style" and scope of the things communicated. Unfortunately, being located in Germany means, that this time collides with my work-hours and if I can allocate some time to attend remains to be seen.
-George _______________________________________________ CentOS-virt mailing list CentOS-virt@centos.org https://lists.centos.org/mailman/listinfo/centos-virt
Regards, Thomas
On Mon, Sep 7, 2015 at 11:40 AM, Johnny Hughes johnny@centos.org wrote:
What we really need is to make the REAL xen RPMs .. the ones produced in this SIG .. work with systemd. These RPMs are produced by Citrix, so we need to get the right.
Just to be clear -- RPMs are produced by the CentOS Virt SIG, which is meant to be an open, community-developed project. At the moment the xen maintainer happens to work for Citrix, but that's neither here nor there.
If there are people who feel like they want to contribute but can't, please speak up. It takes an effort to do things "in the open", as it were, and if I don't know anybody's "listening" it's a lot easier just to do things on my own.
-George
On 09/08/2015 06:41 AM, George Dunlap wrote:
On Mon, Sep 7, 2015 at 11:40 AM, Johnny Hughes johnny@centos.org wrote:
What we really need is to make the REAL xen RPMs .. the ones produced in this SIG .. work with systemd. These RPMs are produced by Citrix, so we need to get the right.
Just to be clear -- RPMs are produced by the CentOS Virt SIG, which is meant to be an open, community-developed project. At the moment the xen maintainer happens to work for Citrix, but that's neither here nor there.
If there are people who feel like they want to contribute but can't, please speak up. It takes an effort to do things "in the open", as it were, and if I don't know anybody's "listening" it's a lot easier just to do things on my own.
-George
Right ... I said 'produced by' in relation to Citrix, but I clearly meant to say 'lead by' instead.
The point I am trying to make is that we (the SIG, as a community) want to produce RPMs here (in the SIG) that are of use to the community and not fragment to a bunch of different individual people making a bunch of different RPM sets that the community does not know who produces, etc.
If we can produce the RPMs instead on the community build system where we (the SIG .. with representation from both the CentOS Project and Citrix) can sign and release the packages then users can be much more sure everything works, etc.
For that to happen, we have to work as a group.
Thanks, Johnny Hughes
not fragment to a bunch of different individual people making a bunch of different RPM sets that the community does not know who produces, etc.
what you're doing its a complete crap, what you said is different from what you did, why you' (centos virt sig) not contributed to the work of fedora guys instead of reinventing the wheel ?
On Tue, Sep 08, 2015 at 10:02:50AM -0300, Itamar Reis Peixoto wrote:
what you're doing its a complete crap, what you said is different from what you did, why you' (centos virt sig) not contributed to the work of fedora guys instead of reinventing the wheel ?
If you're that unhappy with the produced product you are not forced to use it.
On Tue, Sep 8, 2015 at 2:02 PM, Itamar Reis Peixoto itamar@ispbrasil.com.br wrote:
not fragment to a bunch of different individual people making a bunch of different RPM sets that the community does not know who produces, etc.
what you're doing its a complete crap, what you said is different from what you did, why you' (centos virt sig) not contributed to the work of fedora guys instead of reinventing the wheel ?
I don't know if you noticed, but Fedora and CentOS aren't the same distribution. The users target different things.
That said, it would actually be nice to be able to share a lot of the packaging effort with Fedora, if they're willing and if it's possible. It's been something I've thought about for quite a while.
If you have any concrete suggestions, feel free to share them.
-George
On 09/08/2015 08:02 AM, Itamar Reis Peixoto wrote:
not fragment to a bunch of different individual people making a bunch of different RPM sets that the community does not know who produces, etc.
what you're doing its a complete crap, what you said is different from what you did, why you' (centos virt sig) not contributed to the work of fedora guys instead of reinventing the wheel ?
Because we want to have source code that works on both CentOS-6 (based on RHEL 6 Source, which was based on Fedora 12) and CentOS-7 (based on RHEL 7 Sources, which was based on Fedora 18/19).
So, the source code for Fedora 22 will not work with both of those. We DID start with the Fedora 12 version of the RPMs, that worked with CentOS-6 and we have rolled in kernels from the kernel.org LTS tree for stability, etc.
We have been producing a CentOS-6 version for several year now. We now need to make that work with CentOS-7. It is not just as simple as taking Fedora code, that is always latest and greatest and recompiling it. If it was, RHEL (and therefore CentOS) would have no need to exist at all. Everyone could just use Fedora for everything.
FIrstly Centos is primarily a RHEL clone. This means that the primary design decisions are to be as RHEL like as possible. After that there are additions and upgrades.
Secondly Fedora does not actively support Xen. As a long time Xen and RH/Fedora user I have spent lots of time building/rebuilding broken/missing packages in Fedora. Quite frankly Xen under Fedora is somewhat broken. Libvirt support for KVM is very good because RH pays people to support KVM. Xen under the old config format has reasonable support(possibly 60% of features) but under libxl the support is much worse (possibly 30% of features).
Thirdly RedHat has been active at times to remove Xen support in favour of KVM(Their own virtualization technology). Xen has been driven to some extents by the needs of Citrix and although they have helped others build packages for Fedora and libvirt its a good will effort and its hard to expect Citrix to spend effort on work that may not be in their best corporate interests.
On 09/08/2015 09:02 AM, Itamar Reis Peixoto wrote:
not fragment to a bunch of different individual people making a bunch of different RPM sets that the community does not know who produces, etc.
what you're doing its a complete crap, what you said is different from what you did, why you' (centos virt sig) not contributed to the work of fedora guys instead of reinventing the wheel ?
CentOS-virt mailing list CentOS-virt@centos.org https://lists.centos.org/mailman/listinfo/centos-virt
On Tue, Sep 08, 2015 at 10:50:57AM -0400, Alvin Starr wrote:
FIrstly Centos is primarily a RHEL clone. This means that the primary design decisions are to be as RHEL like as possible. After that there are additions and upgrades.
Secondly Fedora does not actively support Xen.
Nonsense. Have you done 'yum install xen' ?
As a long time Xen and RH/Fedora user I have spent lots of time building/rebuilding broken/missing packages in Fedora. Quite frankly Xen under Fedora is somewhat broken.
It is? Please open bugs and CC me on them (ketuzsezr@darnok.org)
Libvirt support for KVM is very good because RH pays people to support KVM. Xen under the old config format has reasonable support(possibly 60% of features) but under libxl the support is much worse (possibly 30% of features).
Please file bugs so we can figure out which ones are missing.
Thirdly RedHat has been active at times to remove Xen support in favour of KVM(Their own virtualization technology).
Not sure I follow as Fedora does not make this distinction.
Xen has been driven to some extents by the needs of Citrix and although they have helped others build packages for Fedora and libvirt its a good will effort and its hard to expect Citrix to spend effort on work that may not be in their best corporate interests.
On 09/08/2015 09:02 AM, Itamar Reis Peixoto wrote:
not fragment to a bunch of different individual people making a bunch of different RPM sets that the community does not know who produces, etc.
what you're doing its a complete crap, what you said is different from what you did, why you' (centos virt sig) not contributed to the work of fedora guys instead of reinventing the wheel ?
CentOS-virt mailing list CentOS-virt@centos.org https://lists.centos.org/mailman/listinfo/centos-virt
-- Alvin Starr || voice: (905)513-7688 Netvel Inc. || Cell: (416)806-0133 alvin@netvel.net ||
CentOS-virt mailing list CentOS-virt@centos.org https://lists.centos.org/mailman/listinfo/centos-virt
On 09/08/2015 10:58 AM, Konrad Rzeszutek Wilk wrote:
On Tue, Sep 08, 2015 at 10:50:57AM -0400, Alvin Starr wrote:
FIrstly Centos is primarily a RHEL clone. This means that the primary design decisions are to be as RHEL like as possible. After that there are additions and upgrades.
Secondly Fedora does not actively support Xen.
Nonsense. Have you done 'yum install xen' ?
Sorry. I mis-spoke there. I should have said RedHad does not actively support Xen.
As a long time Xen and RH/Fedora user I have spent lots of time building/rebuilding broken/missing packages in Fedora. Quite frankly Xen under Fedora is somewhat broken.
It is? Please open bugs and CC me on them (ketuzsezr@darnok.org)
CPU features/flags are just outright is not there. I tend to run into the problems as I am trying to use Xen for my development environment. I have posted fixes and bugs in the past and will in the future. But Xen/Centos does not have a big dedicated development or a small one for that matter. So Xen development will lag a bit. This is not a criticism but just a fact of life.
Libvirt support for KVM is very good because RH pays people to support KVM. Xen under the old config format has reasonable support(possibly 60% of features) but under libxl the support is much worse (possibly 30% of features).
Please file bugs so we can figure out which ones are missing.
When I fight my way through my current provisioning environment I will be likely posting more bugs. I have to admit that I am not the best contributor because often I just fix the bugs. Partly because being outside the community learning all the nuances of posting fixes is way more effort than just fixing them.
Thirdly RedHat has been active at times to remove Xen support in favour of KVM(Their own virtualization technology).
Not sure I follow as Fedora does not make this distinction.
As of the last time I checked you could not build a RedHat 7 kernel with Xen enabled. The point to be made is that Fedora is not RHEL and Centos is more like RHEL.
So comparing Centos to Fedora is like complaining that RHEL should support all the current Fedora packages/features. There is a relationship between all of them but they are not the same.
Xen has been driven to some extents by the needs of Citrix and although they have helped others build packages for Fedora and libvirt its a good will effort and its hard to expect Citrix to spend effort on work that may not be in their best corporate interests.
On 09/08/2015 09:02 AM, Itamar Reis Peixoto wrote:
not fragment to a bunch of different individual people making a bunch of different RPM sets that the community does not know who produces, etc.
what you're doing its a complete crap, what you said is different from what you did, why you' (centos virt sig) not contributed to the work of fedora guys instead of reinventing the wheel ?
CentOS-virt mailing list CentOS-virt@centos.org https://lists.centos.org/mailman/listinfo/centos-virt
-- Alvin Starr || voice: (905)513-7688 Netvel Inc. || Cell: (416)806-0133 alvin@netvel.net ||
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
On Tue, Sep 08, 2015 at 11:22:58AM -0400, Alvin Starr wrote:
On 09/08/2015 10:58 AM, Konrad Rzeszutek Wilk wrote:
On Tue, Sep 08, 2015 at 10:50:57AM -0400, Alvin Starr wrote:
FIrstly Centos is primarily a RHEL clone. This means that the primary design decisions are to be as RHEL like as possible. After that there are additions and upgrades.
Secondly Fedora does not actively support Xen.
Nonsense. Have you done 'yum install xen' ?
Sorry. I mis-spoke there. I should have said RedHad does not actively support Xen.
As a long time Xen and RH/Fedora user I have spent lots of time building/rebuilding broken/missing packages in Fedora. Quite frankly Xen under Fedora is somewhat broken.
It is? Please open bugs and CC me on them (ketuzsezr@darnok.org)
CPU features/flags are just outright is not there. I tend to run into the problems as I am trying to use Xen for my development environment. I have posted fixes and bugs in the past and will in the future.
Excellent!
But Xen/Centos does not have a big dedicated development or a small one for that matter. So Xen development will lag a bit. This is not a criticism but just a fact of life.
Please open bugs for these issues. The CPU features/flags is an important feature that needs to be properly addressed in libxl toolstack. Right now it is a bit of a trainwreck.
Libvirt support for KVM is very good because RH pays people to support KVM. Xen under the old config format has reasonable support(possibly 60% of features) but under libxl the support is much worse (possibly 30% of features).
Please file bugs so we can figure out which ones are missing.
When I fight my way through my current provisioning environment I will be likely posting more bugs.
Fantastic!
I have to admit that I am not the best contributor because often I just fix the bugs.
I would say that is the best contributor!
Partly because being outside the community learning all the nuances of posting fixes is way more effort than just fixing them.
Oh, .. I must be missing something here. Posting fixes seems like an excellent way of removing the issues you had found by them not reappearing in the future?
Thirdly RedHat has been active at times to remove Xen support in favour of KVM(Their own virtualization technology).
Not sure I follow as Fedora does not make this distinction.
As of the last time I checked you could not build a RedHat 7 kernel with Xen enabled.
Odd. I thought you could. The only one missing was the PV framebuffer + intial domain support but the rest were enabled. And that initial domain support was due to them mucking with Kconfig to outright disable it.
The point to be made is that Fedora is not RHEL and Centos is more like RHEL.
So comparing Centos to Fedora is like complaining that RHEL should support all the current Fedora packages/features. There is a relationship between all of them but they are not the same.
Right.
Xen has been driven to some extents by the needs of Citrix and although they have helped others build packages for Fedora and libvirt its a good will effort and its hard to expect Citrix to spend effort on work that may not be in their best corporate interests.
On 09/08/2015 09:02 AM, Itamar Reis Peixoto wrote:
not fragment to a bunch of different individual people making a bunch of different RPM sets that the community does not know who produces, etc.
what you're doing its a complete crap, what you said is different from what you did, why you' (centos virt sig) not contributed to the work of fedora guys instead of reinventing the wheel ?
CentOS-virt mailing list CentOS-virt@centos.org https://lists.centos.org/mailman/listinfo/centos-virt
-- Alvin Starr || voice: (905)513-7688 Netvel Inc. || Cell: (416)806-0133 alvin@netvel.net ||
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
-- Alvin Starr || voice: (905)513-7688 Netvel Inc. || Cell: (416)806-0133 alvin@netvel.net ||
CentOS-virt mailing list CentOS-virt@centos.org https://lists.centos.org/mailman/listinfo/centos-virt
On Tue, Jul 7, 2015 at 10:12 PM, T.Weyergraf T.Weyergraf@virtfinity.de wrote:
On 06/17/2015 04:24 PM, George Dunlap wrote:
At long last, I'd like to announce beta packages for CentOS 7, available from the community build system.
Great to see Xen coming to CentOS 7 !
I gave the virtx7-44-testing packages a spin on a fresh CentOS 7 install (legacy boot, no efi, as there is no xen.efi). However, I was not able to start any HVM or PVHVM guests. Upon create, the DomU was setup but did not do anything, but instead entered a reboot-loop (Dom ID was increased, but no boot output. No bootloader output on the console, despite everything in the guest setup to display on serial console). The exact same guests worked fine with Xen4CentOS xen+kernel packages for CentOS6. Note, that PV DomUs run fine (tested with CentOS5).
Oh -- you know, not sure how I completely missed this. Anyway, yes, the issue was that the original Xen packages were using the CentOS core version of seabios, which includes a patch which breaks Xen HVM. In -candidate I've built a new version of seabios, which (as you've seen) now works.
-George
-
Alvin Starr -
Always Learning -
Chuck Meade -
George Dunlap -
Itamar Reis Peixoto -
Jason Brooks -
John R. Dennison -
Johnny Hughes -
Konrad Rzeszutek Wilk -
Nico Kadel-Garcia -
Pasi Kärkkäinen -
T.Weyergraf