i've F8 as Dom0.
for F8 DomU, pci-passthru devices are visible via lspci *in* DomU.
for a new install of F9 DomU, lcpci is (empty).
there was discussion that PCI-PassThrough might not make it into F9,
http://lists.xensource.com/archives/html/xen-devel/2007-12/msg00454.html "> F9 may well end up lacking features compared to Xen in Fedora 8 & earlier (eg no
PCI device passthrough, or CPU hotplug)"
but release notes,
http://fedoraproject.org/wiki/Features/XenPvops#head-e15c9305e8d715da9d904a1...
make no mention one way or other.
*is* pci-passthru known/supposed to work in F9 DomU?
if so, then i've got a different issue ...
On Tue, May 13, 2008 at 04:08:38PM -0700, snowcrash+xen@gmail.com wrote:
i've F8 as Dom0.
for F8 DomU, pci-passthru devices are visible via lspci *in* DomU.
for a new install of F9 DomU, lcpci is (empty).
there was discussion that PCI-PassThrough might not make it into F9,
http://lists.xensource.com/archives/html/xen-devel/2007-12/msg00454.html "> F9 may well end up lacking features compared to Xen in Fedora 8 & earlier (eg no
PCI device passthrough, or CPU hotplug)"
but release notes,
http://fedoraproject.org/wiki/Features/XenPvops#head-e15c9305e8d715da9d904a1...
make no mention one way or other.
*is* pci-passthru known/supposed to work in F9 DomU?
No. Only block, network and framebuffer devices were implemented in the F9 DomU kernel.
Regards, Dan.
*is* pci-passthru known/supposed to work in F9 DomU?
No. Only block, network and framebuffer devices were implemented in the F9 DomU kernel.
argh. not what i was hoping to hear :-/ but, good to know (should it be added to the 'release notes', above?), i've been spinning my wheels here.
any rough sense for a 'when' it'll be back? soon-to-F10, i'd guess, but *any* add'l guidance would be helpful ...
without it, back to F8 for a couple of DomUs.
thanks!
On Tue, May 13, 2008 at 04:31:30PM -0700, snowcrash+xen@gmail.com wrote:
*is* pci-passthru known/supposed to work in F9 DomU?
No. Only block, network and framebuffer devices were implemented in the F9 DomU kernel.
argh. not what i was hoping to hear :-/ but, good to know (should it be added to the 'release notes', above?), i've been spinning my wheels here.
any rough sense for a 'when' it'll be back? soon-to-F10, i'd guess, but *any* add'l guidance would be helpful ...
This isn't what you'll want to hear but...
To be perfectly honest, it is not really a high priority. Our priorities are getting the DomU stuff merged upstream & working reliably and continuing the Dom0 work, since those impact every single user of Xen. Unfortunately PCI pasthrough is quite a niche userbase, so its hard to justify work on it in the short term given limited resources. If someone has skills & time to volunteer to work on the PCI passthrough stuff.....
Dan.
This isn't what you'll want to hear but...
To be perfectly honest, it is not really a high priority. Our priorities are getting the DomU stuff merged upstream & working reliably and continuing the Dom0 work, since those impact every single user of Xen. Unfortunately PCI pasthrough is quite a niche userbase, so its hard to justify work on it in the short term given limited resources. If someone has skills & time to volunteer to work on the PCI passthrough stuff.....
ouch! a large %age of the boxes we deploy have a firewall/DomU & and a NAS/Domu, each with dedicated, pass'd-thru NICs. without passthru, performance is lousy.
so, iiuc "not really a high priority", i guess -- short of 'growing' someone with the skills -- we're hosed.
the unfortunate irony is we *moved* to Fedora because the passthru support in RHEL was flaky, and Fedora was touted as "the right way to get it". regressing a working feature that differentiates the distro would not have been my first choice ... majority, or otherwise.
thanks for the straight-up !
now to figure out *which* supported distro CAN fit my needs. sigh.
On Tue, May 13, 2008 at 04:55:04PM -0700, snowcrash+xen@gmail.com wrote:
This isn't what you'll want to hear but...
To be perfectly honest, it is not really a high priority. Our priorities are getting the DomU stuff merged upstream & working reliably and continuing the Dom0 work, since those impact every single user of Xen. Unfortunately PCI pasthrough is quite a niche userbase, so its hard to justify work on it in the short term given limited resources. If someone has skills & time to volunteer to work on the PCI passthrough stuff.....
ouch! a large %age of the boxes we deploy have a firewall/DomU & and a NAS/Domu, each with dedicated, pass'd-thru NICs. without passthru, performance is lousy.
so, iiuc "not really a high priority", i guess -- short of 'growing' someone with the skills -- we're hosed.
the unfortunate irony is we *moved* to Fedora because the passthru support in RHEL was flaky, and Fedora was touted as "the right way to get it". regressing a working feature that differentiates the distro would not have been my first choice ... majority, or otherwise.
PCI passthrough *is* supported in RHEL-5 Xen kernels. There was a bug in the RHEL-5.1 Dom0 userspace, but that is fixed in 5.2. AFAIK, any RHEL-5.x guest supports PCI passthrough.
Dan.
On Tue, May 13, 2008 at 04:55:04PM -0700, snowcrash+xen@gmail.com wrote:
ouch! a large %age of the boxes we deploy have a firewall/DomU & and a NAS/Domu, each with dedicated, pass'd-thru NICs. without passthru, performance is lousy.
You're aware that PCI passthrough is insecure? Someone who gets root access to a guest can reprogram the NICs (trivially) to read or write any area of memory in any guest or the dom0. This might be pertinent information if you were expecting your firewall to provide isolation.
Rich.
hi,
You're aware that PCI passthrough is insecure? Someone who gets root access to a guest can reprogram the NICs (trivially) to read or write any area of memory in any guest or the dom0. This might be pertinent information if you were expecting your firewall to provide isolation.
nope. 1st i'm hearing of it ... not that i haven't looked :-/ sigh.
hrm.
so, although this is "just" a RH/Fedora forum, but xen focussed, let me then ask ...
i *want* a distro with
-- X86_64/SMP (AMD multicore) support -- Xen 3.2.x builds & runs both in Dom0 & DomU -- capable of deploying a FW in DomU that does not suffer NIC-performance degradation -- or (apparently) security holes -- stable core that'll keep us 'supported' (e.g., *not* the Fedaora scenario i'm now facing; feature-incomplete until, perhaps, F10+, @ which point F8 -- which we're "stuck" on is unsupported) -- app repos (rpm, srpm, other ...) that are safe/available/reliable for full releases (one example, Bind 9.4.2, which seems to be tough to find for RHEL/Centos 5.1)
*can* i (yet) "have it all"? iiuc, "no" ....
On Wed, May 14, 2008 at 08:23:32AM -0700, snowcrash+xen@gmail.com wrote:
NIC-performance degradation -- or (apparently) security holes
Well, the security thing is a hardware limitation. You'll have to wait for next-gen hardware to support VT-d (I think all of motherboard, processor and PCI cards, though I may be wrong about this). There is some experimental support for VT-d in the latest Xen, but not in RHEL 5.
Rich.
On Wed, May 14, 2008 at 9:54 AM, Richard W.M. Jones rjones@redhat.com wrote:
On Tue, May 13, 2008 at 04:55:04PM -0700, snowcrash+xen@gmail.com wrote:
ouch! a large %age of the boxes we deploy have a firewall/DomU & and a NAS/Domu, each with dedicated, pass'd-thru NICs. without passthru, performance is lousy.
You're aware that PCI passthrough is insecure? Someone who gets root access to a guest can reprogram the NICs (trivially) to read or write any area of memory in any guest or the dom0. This might be pertinent information if you were expecting your firewall to provide isolation.
I figured that a domU having direct hardware access would open security holes; however, the VM I built is for monitoring our Internet connection, and I couldn't figure a way to sniff that traffic without direct hardware access. It's a tightly secured VM with only pinhole access to it in any case. If there's a better way to configure a VM for traffic sniffing, I'd be interested in hearing...
Regards, David
If there's a better way to configure a VM for traffic sniffing, I'd be interested in hearing...
as would i. :-/
my understanding (?) is that passthru to PV domu need to be eliminated to avoid the aforementioned security hole.
that leaves passthru to HVM -- which requires AMD-V (or intel VT-d ...) extension support. and, i _think_ that means xen ver >= 3.2.0 is required.
fedora9's not an option. fedora8's "not going to support it" policy, though understandable on the march to paravirt_ops, leaves little to lean on in terms of community support ...
best option i'm finding so far is Centos51, with a rpmrebuild of xen 320 from src rpm,
http://bits.xensource.com/oss-xen/release/3.2.0/centos-5.1/xen-3.2.0-0xs.cen...
(if there's a 3.2.1 src rpm available, i haven't found it yet ...)
in the process of trying it myself ...
On Wed, May 14, 2008 at 11:48:33AM -0700, snowcrash+xen@gmail.com wrote:
If there's a better way to configure a VM for traffic sniffing, I'd be interested in hearing...
as would i. :-/
my understanding (?) is that passthru to PV domu need to be eliminated to avoid the aforementioned security hole.
that leaves passthru to HVM -- which requires AMD-V (or intel VT-d ...) extension support. and, i _think_ that means xen ver >= 3.2.0 is required.
fedora9's not an option. fedora8's "not going to support it" policy, though understandable on the march to paravirt_ops, leaves little to lean on in terms of community support ...
Sadly that's life with Xen. Upstream Xen has basically stopped all kernel development leaving 'official' Xen kernels stuck on 2.6.28 which is essentially useless for any modern distro. We had the choice between trying to finish off the paravirt_ops port, or dropping Xen entirely :-(
Dan.
Sadly that's life with Xen. Upstream Xen has basically stopped all kernel development leaving 'official' Xen kernels stuck on 2.6.28 which is essentially useless for any modern distro. We had the choice between trying to finish off the paravirt_ops port, or dropping Xen entirely :-(
not criticising the choice (well, much anyway ;-) ) ...
rather, just hunting for options that work -- if even for the short(ish) term
p.s. 2.6.28 a typo? that's 2.6.18, no?
On Wed, May 14, 2008 at 11:58:21AM -0700, snowcrash+xen@gmail.com wrote:
Sadly that's life with Xen. Upstream Xen has basically stopped all kernel development leaving 'official' Xen kernels stuck on 2.6.28 which is essentially useless for any modern distro. We had the choice between trying to finish off the paravirt_ops port, or dropping Xen entirely :-(
not criticising the choice (well, much anyway ;-) ) ...
rather, just hunting for options that work -- if even for the short(ish) term
p.s. 2.6.28 a typo? that's 2.6.18, no?
Yes, 2.6.18
Dan
On Wed, 2008-05-14 at 19:53 +0100, Daniel P. Berrange wrote:
Sadly that's life with Xen. Upstream Xen has basically stopped all kernel development leaving 'official' Xen kernels stuck on 2.6.28 which is essentially useless for any modern distro. We had the choice between trying to finish off the paravirt_ops port, or dropping Xen entirely :-(
What's this? Xen kernel development has stopped? What does that mean - is the GPL project dead?
Regards,
Ranbir
Kanwar Ranbir Sandhu wrote:
On Wed, 2008-05-14 at 19:53 +0100, Daniel P. Berrange wrote:
Sadly that's life with Xen. Upstream Xen has basically stopped all kernel development leaving 'official' Xen kernels stuck on 2.6.28 which is essentially useless for any modern distro. We had the choice between trying to finish off the paravirt_ops port, or dropping Xen entirely :-(
What's this? Xen kernel development has stopped? What does that mean - is the GPL project dead?
Not at all.
In fact, I'd strongly disagree with Daniel's characterisation that Xen has "stopped all kernel development" Redhat need to "finish off" the paravirt_ops port. I've been working on it full time for the last couple of years, and have done the vast majority of the work needed to get paravirt_ops working.
Redhat have contributed valuable work in areas like the paravirtual framebuffer device, and are working on 64-bit and dom0 support. But all of that is based on the work I've been doing on paravirt-ops infrastructure itself and the Xen implementation which uses it.
I'm still actively working on pvops/Xen, and currently focusing on bringing it up to feature parity with the old 2.6.18-xen patches. In the last few weeks I've implemented balloon support, save/restore and starting work on pv-hvm driver support.
Meanwhile, open source Xen is also being actively developed by the original Xen developers and anyone who wishes to contribute.
J
On Wed, May 28, 2008 at 11:32:12AM +0100, Jeremy Fitzhardinge wrote:
Kanwar Ranbir Sandhu wrote:
On Wed, 2008-05-14 at 19:53 +0100, Daniel P. Berrange wrote:
Sadly that's life with Xen. Upstream Xen has basically stopped all kernel development leaving 'official' Xen kernels stuck on 2.6.28 which is essentially useless for any modern distro. We had the choice between trying to finish off the paravirt_ops port, or dropping Xen entirely :-(
What's this? Xen kernel development has stopped? What does that mean - is the GPL project dead?
Not at all.
In fact, I'd strongly disagree with Daniel's characterisation that Xen has "stopped all kernel development" Redhat need to "finish off" the paravirt_ops port. I've been working on it full time for the last couple of years, and have done the vast majority of the work needed to get paravirt_ops working.
Redhat have contributed valuable work in areas like the paravirtual framebuffer device, and are working on 64-bit and dom0 support. But all of that is based on the work I've been doing on paravirt-ops infrastructure itself and the Xen implementation which uses it.
Which reminds me that would be really nice to get a binary rpm for kernel-xen with dom0 patches in it to try it and start reporting bugs.. :)
I'm still actively working on pvops/Xen, and currently focusing on bringing it up to feature parity with the old 2.6.18-xen patches. In the last few weeks I've implemented balloon support, save/restore and starting work on pv-hvm driver support.
This is really excellent news! Thanks a lot for doing this work.
Hopefully we'll see these features in rawhide/F10 kernel-xen soon :)
-- Pasi
On Wed, May 28, 2008 at 03:51:10PM +0300, Pasi K?rkk?inen wrote:
On Wed, May 28, 2008 at 11:32:12AM +0100, Jeremy Fitzhardinge wrote:
Kanwar Ranbir Sandhu wrote:
On Wed, 2008-05-14 at 19:53 +0100, Daniel P. Berrange wrote:
Sadly that's life with Xen. Upstream Xen has basically stopped all kernel development leaving 'official' Xen kernels stuck on 2.6.28 which is essentially useless for any modern distro. We had the choice between trying to finish off the paravirt_ops port, or dropping Xen entirely :-(
What's this? Xen kernel development has stopped? What does that mean - is the GPL project dead?
Not at all.
In fact, I'd strongly disagree with Daniel's characterisation that Xen has "stopped all kernel development" Redhat need to "finish off" the paravirt_ops port. I've been working on it full time for the last couple of years, and have done the vast majority of the work needed to get paravirt_ops working.
Redhat have contributed valuable work in areas like the paravirtual framebuffer device, and are working on 64-bit and dom0 support. But all of that is based on the work I've been doing on paravirt-ops infrastructure itself and the Xen implementation which uses it.
Which reminds me that would be really nice to get a binary rpm for kernel-xen with dom0 patches in it to try it and start reporting bugs.. :)
This is intended to go into rawhide sometime in the reasonably near future, now that the critical F9 kerne-xen bugs have mostly been ironed out.
Dan.
On Wed, May 28, 2008 at 11:32:12AM +0100, Jeremy Fitzhardinge wrote:
Kanwar Ranbir Sandhu wrote:
On Wed, 2008-05-14 at 19:53 +0100, Daniel P. Berrange wrote:
Sadly that's life with Xen. Upstream Xen has basically stopped all kernel development leaving 'official' Xen kernels stuck on 2.6.28 which is essentially useless for any modern distro. We had the choice between trying to finish off the paravirt_ops port, or dropping Xen entirely :-(
What's this? Xen kernel development has stopped? What does that mean - is the GPL project dead?
Not at all.
In fact, I'd strongly disagree with Daniel's characterisation that Xen has "stopped all kernel development" Redhat need to "finish off" the paravirt_ops port. I've been working on it full time for the last couple of years, and have done the vast majority of the work needed to get paravirt_ops working.
When I said 'stopped all kernel development' I was referring to the original 'linux-xen-2.6' tree, which is what we've been shipping in Fedora until this point. Obviously paravirt_ops Xen development is still active & increasingly so.
Regards, Dan.
On Wed, May 28, 2008 at 11:32:12AM +0100, Jeremy Fitzhardinge wrote:
Kanwar Ranbir Sandhu wrote:
On Wed, 2008-05-14 at 19:53 +0100, Daniel P. Berrange wrote:
Sadly that's life with Xen. Upstream Xen has basically stopped all kernel development leaving 'official' Xen kernels stuck on 2.6.28 which is essentially useless for any modern distro. We had the choice between trying to finish off the paravirt_ops port, or dropping Xen entirely :-(
What's this? Xen kernel development has stopped? What does that mean - is the GPL project dead?
Not at all.
In fact, I'd strongly disagree with Daniel's characterisation that Xen has "stopped all kernel development" Redhat need to "finish off" the paravirt_ops port. I've been working on it full time for the last couple of years, and have done the vast majority of the work needed to get paravirt_ops working.
Redhat have contributed valuable work in areas like the paravirtual framebuffer device, and are working on 64-bit and dom0 support. But all of that is based on the work I've been doing on paravirt-ops infrastructure itself and the Xen implementation which uses it.
I'm still actively working on pvops/Xen, and currently focusing on bringing it up to feature parity with the old 2.6.18-xen patches. In the last few weeks I've implemented balloon support, save/restore and starting work on pv-hvm driver support.
Btw is this work available in some repository?
-- Pasi
Pasi Kärkkäinen wrote:
Btw is this work available in some repository?
It's in Ingo's x86 git tree. See http://people.redhat.com/mingo/tip.git/README for details.
J
On Wed, May 28, 2008 at 09:08:35PM +0100, Jeremy Fitzhardinge wrote:
Pasi Kärkkäinen wrote:
Btw is this work available in some repository?
It's in Ingo's x86 git tree. See http://people.redhat.com/mingo/tip.git/README for details.
Ok. Thanks.
Is it 2.6.27 stuff, or is it already in 2.6.26?
-- Pasi
Pasi Kärkkäinen wrote:
On Wed, May 28, 2008 at 09:08:35PM +0100, Jeremy Fitzhardinge wrote:
Pasi Kärkkäinen wrote:
Btw is this work available in some repository?
It's in Ingo's x86 git tree. See http://people.redhat.com/mingo/tip.git/README for details.
Ok. Thanks.
Is it 2.6.27 stuff, or is it already in 2.6.26?
Most of it is targeted for .27. Everything that's planned for .26 is already in Linus' tree.
J
xen@lists.stg.fedoraproject.org