This information will be mirrored on the Xen 4.3 Roadmap wiki page:
http://wiki.xen.org/wiki/Xen_Roadmap/4.3
At this point, code will begin freezing.
This means that every patch will need an exception to be accepted. The
bar for acceptance will be relatively low this week, but will continue
to raise until the May 6th code freeze.
The key goals we''re focusing on now, in order, are as follows:
1. Have a bug-free 4.3 release
2. Have an awesome 4.3 release
3. Have a 4.3 release that happens on schedule (ready by June 15th)
So my goal right now is to ensure, to the best of my ability, that:
1. No new bugs are introduced that will not be discovered before the
release
2. If no code is added, then either:
- it does case the release to slip
- if it causes the release to slip, it was worth the cost.
If you are a maintainer or committer, please help me in evaluating new
patches according to these criteria. (Bug fixes are fine of course.)
If you are submitting patches, please consider these criteria before
submitting; and if you think you want to submit it anyway, consider
making a brief case for acceptance.
The most important thing in making a case is to answer the question,
"If there are bugs in this patch, will they be discovered before the
June 15h release?" The second most important thing is to consider the
cost/benefit analysis of bugs that are found: what is the risk of
introducing a bug which will delay the release, vs the benefit it will
have in making the release better?
= Timeline
We are planning on a 9-month release cycle. Based on that, below are
our estimated dates:
* Feature freeze: 25 March 2013
* Code freezing point: 15 April 2013 <== We are here
* First RC: 6 May 2013
* Release: 17 June 2013
The RCs and release will of course depend on stability and bugs, and
will therefore be fairly unpredictable. Each new feature will be
considered on a case-by-case basis; but the general rule will be as
follows:
Last updated: 16 April 2013
= Feature tracking
Below is a list of features we''re tracking for this release. Please
respond to this mail with any updates to the status.
There are a number of items whose owners are marked as "?". If you
are working on this, or know who is working on it, please respond and
let me know. Alternately, if you would *like* to work on it, please
let me know as well.
And if there is something you''re working on you''d like
tracked, please
respond, and I will add it to the list.
NB: Several of the items on this list are from external projects:
linux, qemu, and libvirt. These are not part of the Xen tree, but are
directly related to our users'' experience (e.g., work in Linux or
qemu) or to integration with other important projects (e.g., libvirt
bindings). Since all of these are part of the Xen community work, and
comes from the same pool of labor, it makes sense to track the
progress here, even though they won''t explicitly be released as part
of 4.3.
Meanings of prognoses:
- Excellent: It would be very unlikely for this not to be finished in time.
- Good: Everything is on track, and is likely to make it.
- Fair: A pretty good chance of making it, but not as certain
- Poor: Likely not to make it unless intervention is made
- Not for 4.3: Self-explanatory
== Completed =
* Serial console improvements
-EHCI debug port
* Default to QEMU upstream (partial)
- pci pass-thru (external)
- enable dirtybit tracking during migration (external)
- xl cd-{insert,eject} (external)
* CPUID-based idle (don''t rely on ACPI info f/ dom0)
* Persistent grants for blk (external)
- Linux
- qemu
* Allow XSM to override IS_PRIV checks in the hypervisor
* Scalability: 16TiB of RAM
* xl QXL Spice support
== Bugs =
* xl, compat mode, and older kernels
owner: ?
Many older 32-bit PV kernels that can run on a 64-bit hypervisor with
xend do not work when started with xl. The following work-around seems to
work:
xl create -p lightning.cfg
xenstore-write /local/domain/$(xl domid
lightning)/device/vbd/51713/protocol x86_32-abi
xl unpause lightning
This node is normally written by the guest kernel, but for older kernels
seems not to be. xend must have a work-around; port this work-around to xl.
* AMD NPT performance regression after c/s 24770:7f79475d3de7
owner: ?
Reference: http://marc.info/?l=xen-devel&m=135075376805215
* qemu-upstream: cd-insert and cd-eject not working
http://marc.info/?l=xen-devel&m=135850249808960
* Install into /usr/local by default
owner: Ian Campbell
* Revert Jan''s debugging patch (commit bd9be94)
owner: Jan Beulich
* Race condition in claim hypercall
owner: Ian Jackson, Konrad Wilk
* Remove hardcoded mobprobe''s in xencommons
owner: ?
status: ?
== Not yet complete =
* ARM v7 server port
owner: ijc@citrix
prognosis: Excellent
status: ?
* ARM v8 server port (tech preview)
owner: ijc@citrix
status: ?
prognosis: Tech preview only
* NUMA scheduler affinity
critical
owner: dario@citrix
status: Patches posted
prognosis: Excellent
* Default to QEMU upstream
> Add "intel-hda" to xmexample file, since it works with 64-bit
Win7/8
- qemu-based stubdom (Linux or BSD libc)
owner: anthony@citrix
status: in progress
prognosis: ?
qemu-upstream needs a more fully-featured libc than exists in
mini-os. Either work on a minimalist linux-based stubdom with
glibc, or port one of the BSD libcs to minios.
* Multi-vector PCI MSI (support at least for Dom0)
owner: jan@suse
status: Patches posted for Intel; AMD not yet done
prognosis: Fair
* vTPM updates
owner: Daniel DeGraaf @ NSA
status: some patches submitted, more in progress
prognosis: Good
* xl PVUSB pass-through for PV guests
* xl PVUSB pass-through for HVM guests
owner: George
status: ?
prognosis: Poor
xm/xend supports PVUSB pass-through to guests with PVUSB drivers
(both PV and HVM guests).
- port the xm/xend functionality to xl.
- this PVUSB feature does not require support or emulation from Qemu.
- upstream the Linux frontend/backend drivers. Current
work-in-progress versions are in Konrad''s git tree.
- James Harper''s GPLPV drivers for Windows include PVUSB frontend
drivers.
* xl USB pass-through for HVM guests using Qemu USB emulation
owner: George
status: v4 patch series posted
prognosis: Fair
* xl: passing more defaults in configuration in xl.conf
owner: ?
There are a number of options for which it might be useful to pass a
default in xl.conf. For example, if we could have a default
"backend" parameter for vifs, then it would be easy to switch back
and forth between a backend in a driver domain and a backend in dom0.
* Rationalized backend scripts
owner: roger@citrix
status: libxl hotplug sumbmitted. Protocol still needs to be finalized.
prognosis: Good
* Scripts for driver domains (depends on backend scripts)
owner: roger@citrix
status:
prognosis: Fair
On Tue, 2013-04-16 at 13:22 +0100, George Dunlap wrote:> This information will be mirrored on the Xen 4.3 Roadmap wiki page: > http://wiki.xen.org/wiki/Xen_Roadmap/4.3 > > At this point, code will begin freezing. > > This means that every patch will need an exception to be accepted. The > bar for acceptance will be relatively low this week, but will continue > to raise until the May 6th code freeze. > > The key goals we''re focusing on now, in order, are as follows: > 1. Have a bug-free 4.3 release > 2. Have an awesome 4.3 release > 3. Have a 4.3 release that happens on schedule (ready by June 15th) > > So my goal right now is to ensure, to the best of my ability, that: > 1. No new bugs are introduced that will not be discovered before the > release > 2. If no code is added, then either:^new?> - it does case the release to slip^not cause ?> - if it causes the release to slip, it was worth the cost.[...]> * Install into /usr/local by default > owner: Ian CampbellDone. Ian.
On 16/04/13 13:37, Ian Campbell wrote:> On Tue, 2013-04-16 at 13:22 +0100, George Dunlap wrote: >> This information will be mirrored on the Xen 4.3 Roadmap wiki page: >> http://wiki.xen.org/wiki/Xen_Roadmap/4.3 >> >> At this point, code will begin freezing. >> >> This means that every patch will need an exception to be accepted. The >> bar for acceptance will be relatively low this week, but will continue >> to raise until the May 6th code freeze. >> >> The key goals we''re focusing on now, in order, are as follows: >> 1. Have a bug-free 4.3 release >> 2. Have an awesome 4.3 release >> 3. Have a 4.3 release that happens on schedule (ready by June 15th) >> >> So my goal right now is to ensure, to the best of my ability, that: >> 1. No new bugs are introduced that will not be discovered before the >> release >> 2. If no code is added, then either: > ^new?Er, not sure how that got past the proofreading... yes, it should say: 2. If new code is added, then either: - It does not cause the release to slip - If it causes the release to slip, then it was worth the cost.>> * Install into /usr/local by default >> owner: Ian CampbellGreat, thanks. -George
On Tue, Apr 16, 2013 at 1:22 PM, George Dunlap <George.Dunlap@eu.citrix.com> wrote:> > == Bugs => > * xl, compat mode, and older kernels > owner: ? > Many older 32-bit PV kernels that can run on a 64-bit hypervisor with > xend do not work when started with xl. The following work-around seems to > work: > xl create -p lightning.cfg > xenstore-write /local/domain/$(xl domid > lightning)/device/vbd/51713/protocol x86_32-abi > xl unpause lightning > This node is normally written by the guest kernel, but for older kernels > seems not to be. xend must have a work-around; port this work-around to xl.> * Remove hardcoded mobprobe''s in xencommons > owner: ? > status: ?We need someone to step up for each of these two. -George
On Tue, Apr 16, 2013 at 1:22 PM, George Dunlap <George.Dunlap@eu.citrix.com> wrote:> == Bugs = > > * qemu-upstream: cd-insert and cd-eject not working > http://marc.info/?l=xen-devel&m=135850249808960Anthony, is this one on your radar? -George
>>> On 16.04.13 at 14:22, George Dunlap <George.Dunlap@eu.citrix.com> wrote: > This information will be mirrored on the Xen 4.3 Roadmap wiki page: > http://wiki.xen.org/wiki/Xen_Roadmap/4.3 > > At this point, code will begin freezing. > > This means that every patch will need an exception to be accepted. The > bar for acceptance will be relatively low this week, but will continue > to raise until the May 6th code freeze.So how does this "accepting an exception" look from a formal POV? Do non-bug-fix patches need an additional ACK from you? Or are committers expected to use common sense? Or yet something else? Jan
On 16/04/13 13:57, Jan Beulich wrote:>>>> On 16.04.13 at 14:22, George Dunlap <George.Dunlap@eu.citrix.com> wrote: >> This information will be mirrored on the Xen 4.3 Roadmap wiki page: >> http://wiki.xen.org/wiki/Xen_Roadmap/4.3 >> >> At this point, code will begin freezing. >> >> This means that every patch will need an exception to be accepted. The >> bar for acceptance will be relatively low this week, but will continue >> to raise until the May 6th code freeze. > So how does this "accepting an exception" look from a formal POV? > Do non-bug-fix patches need an additional ACK from you? Or are > committers expected to use common sense? Or yet something else?Well, I have not been elected to any position, nor am I the benevolent dictator, so I am not in a position to dictate to committers what to commit and what not to commit. However, I would respectfully request that committers ask for an Ack from me, if that is acceptable to everyone. -George
>>> On 16.04.13 at 15:00, George Dunlap <george.dunlap@eu.citrix.com> wrote: > On 16/04/13 13:57, Jan Beulich wrote: >>>>> On 16.04.13 at 14:22, George Dunlap <George.Dunlap@eu.citrix.com> wrote: >>> This information will be mirrored on the Xen 4.3 Roadmap wiki page: >>> http://wiki.xen.org/wiki/Xen_Roadmap/4.3 >>> >>> At this point, code will begin freezing. >>> >>> This means that every patch will need an exception to be accepted. The >>> bar for acceptance will be relatively low this week, but will continue >>> to raise until the May 6th code freeze. >> So how does this "accepting an exception" look from a formal POV? >> Do non-bug-fix patches need an additional ACK from you? Or are >> committers expected to use common sense? Or yet something else? > > Well, I have not been elected to any position, nor am I the benevolent > dictator, so I am not in a position to dictate to committers what to > commit and what not to commit. > > However, I would respectfully request that committers ask for an Ack > from me, if that is acceptable to everyone.That''s fine with me of course, in the hope that I won''t forget once in a while. Jan
On Tue, Apr 16, 2013 at 01:50:26PM +0100, George Dunlap wrote:> On Tue, Apr 16, 2013 at 1:22 PM, George Dunlap > <George.Dunlap@eu.citrix.com> wrote: > > > > > == Bugs => > > > * xl, compat mode, and older kernels > > owner: ? > > Many older 32-bit PV kernels that can run on a 64-bit hypervisor with > > xend do not work when started with xl. The following work-around seems to > > work: > > xl create -p lightning.cfg > > xenstore-write /local/domain/$(xl domid > > lightning)/device/vbd/51713/protocol x86_32-abi > > xl unpause lightning > > This node is normally written by the guest kernel, but for older kernels > > seems not to be. xend must have a work-around; port this work-around to xl. >I played with Xend several years ago, I can try to have a look at this.> > > * Remove hardcoded mobprobe''s in xencommons > > owner: ? > > status: ? >Maybe this as well if nobody else steps up. Wei.> We need someone to step up for each of these two.> > -George > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel
On Tue, Apr 16, 2013 at 1:22 PM, George Dunlap <George.Dunlap@eu.citrix.com> wrote:> * Default to QEMU upstream > > Add "intel-hda" to xmexample file, since it works with 64-bit Win7/8 > - qemu-based stubdom (Linux or BSD libc) > owner: anthony@citrix > status: in progress > prognosis: ? > qemu-upstream needs a more fully-featured libc than exists in > mini-os. Either work on a minimalist linux-based stubdom with > glibc, or port one of the BSD libcs to minios.Anthony, what''s the status on this? At the moment we default to qemu-upstream if the DM is running in dom0, and to qemu-traditional if we''re running in a stubdom. What that means is that if someone installs the "normal" way, and then decides to upgrade to qemu stub domains, then their qemu version will downgrade. Just as a data point: I installed Windows XP on qemu-upstream, and then switched to qemu-default. XP booted, but a bunch of the devices, including the VGA and the ethernet, changed and wanted new driver installed. But it didn''t have an ethernet driver, so it couldn''t download the drivers from the web. (Presumably if it had had PV tools installed it wouldn''t have been an issue.) So not terrible, but not great: I would still really like to get this in if we can. Thoughts? -George
On Tue, Apr 16, 2013 at 4:02 PM, Wei Liu <wei.liu2@citrix.com> wrote:> On Tue, Apr 16, 2013 at 01:50:26PM +0100, George Dunlap wrote: >> On Tue, Apr 16, 2013 at 1:22 PM, George Dunlap >> <George.Dunlap@eu.citrix.com> wrote: >> >> > >> > == Bugs =>> > >> > * xl, compat mode, and older kernels >> > owner: ? >> > Many older 32-bit PV kernels that can run on a 64-bit hypervisor with >> > xend do not work when started with xl. The following work-around seems to >> > work: >> > xl create -p lightning.cfg >> > xenstore-write /local/domain/$(xl domid >> > lightning)/device/vbd/51713/protocol x86_32-abi >> > xl unpause lightning >> > This node is normally written by the guest kernel, but for older kernels >> > seems not to be. xend must have a work-around; port this work-around to xl. >> > > I played with Xend several years ago, I can try to have a look at this. > >> >> > * Remove hardcoded mobprobe''s in xencommons >> > owner: ? >> > status: ? >> > > Maybe this as well if nobody else steps up.Great, thanks. -George
On 16/04/13 16:16, George Dunlap wrote:> On Tue, Apr 16, 2013 at 1:22 PM, George Dunlap > <George.Dunlap@eu.citrix.com> wrote: > >> * Default to QEMU upstream >> > Add "intel-hda" to xmexample file, since it works with 64-bit Win7/8 >> - qemu-based stubdom (Linux or BSD libc) >> owner: anthony@citrix >> status: in progress >> prognosis: ? >> qemu-upstream needs a more fully-featured libc than exists in >> mini-os. Either work on a minimalist linux-based stubdom with >> glibc, or port one of the BSD libcs to minios. > > Anthony, what''s the status on this?I''m close to send patches for it, and it should be sent before the end of this week. But it will be more of a tech preview I suppose, as I did not try to have the vga working, yet.> At the moment we default to qemu-upstream if the DM is running in > dom0, and to qemu-traditional if we''re running in a stubdom. What > that means is that if someone installs the "normal" way, and then > decides to upgrade to qemu stub domains, then their qemu version will > downgrade. > > Just as a data point: I installed Windows XP on qemu-upstream, and > then switched to qemu-default. XP booted, but a bunch of the devices, > including the VGA and the ethernet, changed and wanted new driver > installed. But it didn''t have an ethernet driver, so it couldn''t > download the drivers from the web. (Presumably if it had had PV tools > installed it wouldn''t have been an issue.) > > So not terrible, but not great: I would still really like to get this > in if we can. > > Thoughts?-- Anthony PERARD
On Tue, Apr 16, 2013 at 04:20:09PM +0100, George Dunlap wrote:> On Tue, Apr 16, 2013 at 4:02 PM, Wei Liu <wei.liu2@citrix.com> wrote: > > On Tue, Apr 16, 2013 at 01:50:26PM +0100, George Dunlap wrote: > >> On Tue, Apr 16, 2013 at 1:22 PM, George Dunlap > >> <George.Dunlap@eu.citrix.com> wrote: > >> > >> > > >> > == Bugs => >> > > >> > * xl, compat mode, and older kernels > >> > owner: ? > >> > Many older 32-bit PV kernels that can run on a 64-bit hypervisor with > >> > xend do not work when started with xl. The following work-around seems to > >> > work: > >> > xl create -p lightning.cfg > >> > xenstore-write /local/domain/$(xl domid > >> > lightning)/device/vbd/51713/protocol x86_32-abi > >> > xl unpause lightning > >> > This node is normally written by the guest kernel, but for older kernels > >> > seems not to be. xend must have a work-around; port this work-around to xl. > >> > > > > I played with Xend several years ago, I can try to have a look at this. > >Quick question, anyone has kernel image that''s needs this workaround? Wei.> >> > >> > * Remove hardcoded mobprobe''s in xencommons > >> > owner: ? > >> > status: ? > >> > > > > Maybe this as well if nobody else steps up. > > Great, thanks. > > > -George
On 16/04/13 17:11, Wei Liu wrote:> On Tue, Apr 16, 2013 at 04:20:09PM +0100, George Dunlap wrote: >> On Tue, Apr 16, 2013 at 4:02 PM, Wei Liu <wei.liu2@citrix.com> wrote: >>> On Tue, Apr 16, 2013 at 01:50:26PM +0100, George Dunlap wrote: >>>> On Tue, Apr 16, 2013 at 1:22 PM, George Dunlap >>>> <George.Dunlap@eu.citrix.com> wrote: >>>> >>>>> == Bugs =>>>>> >>>>> * xl, compat mode, and older kernels >>>>> owner: ? >>>>> Many older 32-bit PV kernels that can run on a 64-bit hypervisor with >>>>> xend do not work when started with xl. The following work-around seems to >>>>> work: >>>>> xl create -p lightning.cfg >>>>> xenstore-write /local/domain/$(xl domid >>>>> lightning)/device/vbd/51713/protocol x86_32-abi >>>>> xl unpause lightning >>>>> This node is normally written by the guest kernel, but for older kernels >>>>> seems not to be. xend must have a work-around; port this work-around to xl. >>> I played with Xend several years ago, I can try to have a look at this. >>> > Quick question, anyone has kernel image that''s needs this workaround?The original thread that started this is here: http://www.gossamer-threads.com/lists/xen/devel/258488?do=post_view_threaded It mentioned using Debian etch''s built-in 2.6.16.33-xen kernel. -George
Stefano Stabellini
2013-Apr-18 11:30 UTC
Re: Xen 4.3 development update CODE FREEZE HAS_BEGUN
On Tue, 16 Apr 2013, George Dunlap wrote:> * Rationalized backend scripts > owner: roger@citrix > status: libxl hotplug sumbmitted. Protocol still needs to be finalized. > prognosis: GoodOK> * Scripts for driver domains (depends on backend scripts) > owner: roger@citrix > status: > prognosis: FairAre there going to make 4.3?
Roger Pau Monné
2013-Apr-18 14:50 UTC
Re: Xen 4.3 development update CODE FREEZE HAS_BEGUN
On 18/04/13 13:30, Stefano Stabellini wrote:> On Tue, 16 Apr 2013, George Dunlap wrote: >> * Rationalized backend scripts >> owner: roger@citrix >> status: libxl hotplug sumbmitted. Protocol still needs to be finalized. >> prognosis: Good > > OK > >> * Scripts for driver domains (depends on backend scripts) >> owner: roger@citrix >> status: >> prognosis: Fair > > Are there going to make 4.3?Regarding "Rationalized backend scripts", or what I usually call new libxl hotplug interface, I think it could make it to 4.3. Here is a small list about the pros/cons of taking that from my POV: Cons: - Touches generic device addition/removal code, and domain creation/destruction. - It introduces a new interface that is well defined and that we plan to support, we have to be sure the interface is right. Pros: - All the code touched is exercised every time a domain/device is created/destroyed, so the test system should be able to detect any problems with that easily. - Brings new functionality (iSCSI disks), which is not present in libxl/xl, and should be considered a regression from xm. - The new hotplug interface could be released as a tech preview, guaranteeing us that we could still change it if we feel it doesn''t really suit our needs (I think it''s best to have it as a tech preview rather than not having it at all). - The new iSCSI libxl/xl disk functionality could also be considered a tech preview, again it''s best to have it like that rather than not having it at all, I''ve heard quite a lot of people asking about iSCSI support in Xen.
On 18/04/13 15:50, Roger Pau Monne wrote:> On 18/04/13 13:30, Stefano Stabellini wrote: >> On Tue, 16 Apr 2013, George Dunlap wrote: >>> * Rationalized backend scripts >>> owner: roger@citrix >>> status: libxl hotplug sumbmitted. Protocol still needs to be finalized. >>> prognosis: Good >> OK >> >>> * Scripts for driver domains (depends on backend scripts) >>> owner: roger@citrix >>> status: >>> prognosis: Fair >> Are there going to make 4.3? > Regarding "Rationalized backend scripts", or what I usually call new > libxl hotplug interface, I think it could make it to 4.3. Here is a > small list about the pros/cons of taking that from my POV: > > Cons: > - Touches generic device addition/removal code, and domain > creation/destruction. > > - It introduces a new interface that is well defined and that we plan > to support, we have to be sure the interface is right. > > > Pros: > - All the code touched is exercised every time a domain/device is > created/destroyed, so the test system should be able to detect any > problems with that easily.OK, why don''t we check it in, and if it seems to be causing carnage we''ll revert it. I''ll reply to the series with an ack. -George
On Tue, Apr 16, 2013 at 05:24:05PM +0100, George Dunlap wrote:> On 16/04/13 17:11, Wei Liu wrote: > > On Tue, Apr 16, 2013 at 04:20:09PM +0100, George Dunlap wrote: > >> On Tue, Apr 16, 2013 at 4:02 PM, Wei Liu <wei.liu2@citrix.com> wrote: > >>> On Tue, Apr 16, 2013 at 01:50:26PM +0100, George Dunlap wrote: > >>>> On Tue, Apr 16, 2013 at 1:22 PM, George Dunlap > >>>> <George.Dunlap@eu.citrix.com> wrote: > >>>> > >>>>> == Bugs => >>>>> > >>>>> * xl, compat mode, and older kernels > >>>>> owner: ? > >>>>> Many older 32-bit PV kernels that can run on a 64-bit hypervisor with > >>>>> xend do not work when started with xl. The following work-around seems to > >>>>> work: > >>>>> xl create -p lightning.cfg > >>>>> xenstore-write /local/domain/$(xl domid > >>>>> lightning)/device/vbd/51713/protocol x86_32-abi > >>>>> xl unpause lightning > >>>>> This node is normally written by the guest kernel, but for older kernels > >>>>> seems not to be. xend must have a work-around; port this work-around to xl. > >>> I played with Xend several years ago, I can try to have a look at this. > >>> > > Quick question, anyone has kernel image that''s needs this workaround? > > The original thread that started this is here: > > http://www.gossamer-threads.com/lists/xen/devel/258488?do=post_view_threaded > > It mentioned using Debian etch''s built-in 2.6.16.33-xen kernel.Now I''ve identified the problem, should I write a patch for it or should I wait till 4.4 window is open? Wei.> > -George
--On 18 April 2013 16:50:06 +0200 Roger Pau Monné <roger.pau@citrix.com> wrote:> - The new iSCSI libxl/xl disk functionality could also be considered a > tech preview, again it's best to have it like that rather than not > having it at all, I've heard quite a lot of people asking about iSCSI > support in Xen.I don't quite understand this point. We've been happily using iSCSI support (i.e. dom0 iSCSI block devices) with xen 4.2 for ages, using libxl. I am 99.9% sure we have this working with xl too for testing. Why does Xen even care whether /dev/sdc is a SATA disk or a SCSI disk? Completely untested, but if upstream QEMU device model is the 4.3 default, upstream QEMU has its own native iscsi client built in. Won't that 'just work'? (with libxl, perhaps not xl) -- Alex Bligh _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On Thu, 2013-04-18 at 19:09 +0100, Wei Liu wrote:> On Tue, Apr 16, 2013 at 05:24:05PM +0100, George Dunlap wrote: > > On 16/04/13 17:11, Wei Liu wrote: > > > On Tue, Apr 16, 2013 at 04:20:09PM +0100, George Dunlap wrote: > > >> On Tue, Apr 16, 2013 at 4:02 PM, Wei Liu <wei.liu2@citrix.com> wrote: > > >>> On Tue, Apr 16, 2013 at 01:50:26PM +0100, George Dunlap wrote: > > >>>> On Tue, Apr 16, 2013 at 1:22 PM, George Dunlap > > >>>> <George.Dunlap@eu.citrix.com> wrote: > > >>>> > > >>>>> == Bugs => > >>>>> > > >>>>> * xl, compat mode, and older kernels > > >>>>> owner: ? > > >>>>> Many older 32-bit PV kernels that can run on a 64-bit hypervisor with > > >>>>> xend do not work when started with xl. The following work-around seems to > > >>>>> work: > > >>>>> xl create -p lightning.cfg > > >>>>> xenstore-write /local/domain/$(xl domid > > >>>>> lightning)/device/vbd/51713/protocol x86_32-abi > > >>>>> xl unpause lightning > > >>>>> This node is normally written by the guest kernel, but for older kernels > > >>>>> seems not to be. xend must have a work-around; port this work-around to xl. > > >>> I played with Xend several years ago, I can try to have a look at this. > > >>> > > > Quick question, anyone has kernel image that''s needs this workaround? > > > > The original thread that started this is here: > > > > http://www.gossamer-threads.com/lists/xen/devel/258488?do=post_view_threaded > > > > It mentioned using Debian etch''s built-in 2.6.16.33-xen kernel. > > Now I''ve identified the problem, should I write a patch for it or should > I wait till 4.4 window is open?Write a patch, we should at least consider it as a bug fix for 4.3. Ian
Roger Pau Monné
2013-Apr-19 08:07 UTC
Re: Xen 4.3 development update CODE FREEZE HAS_BEGUN
On 18/04/13 21:58, Alex Bligh wrote:> > > --On 18 April 2013 16:50:06 +0200 Roger Pau Monné <roger.pau@citrix.com> > wrote: > >> - The new iSCSI libxl/xl disk functionality could also be considered a >> tech preview, again it's best to have it like that rather than not >> having it at all, I've heard quite a lot of people asking about iSCSI >> support in Xen. > > I don't quite understand this point. We've been happily using iSCSI > support (i.e. dom0 iSCSI block devices) with xen 4.2 for ages, > using libxl. I am 99.9% sure we have this working with xl too for > testing. Why does Xen even care whether /dev/sdc is a SATA disk or > a SCSI disk?Sure, you can attach the iSCSI disk yourself on the Dom0 and pass that block device to the DomU, or you could even have a hotplug script that does this automatically. The nice thing from this implementation (apart from the fact that you can specify iSCSI targets in the DomU config file, so you don't have to care about plugging them), is that it allows to offload part of the work that is usually done in the "add" phase to a new action called "prepare", that when performing migration is executed before the guest on the sender side is paused, so the blackout phase during migration is reduced.> > Completely untested, but if upstream QEMU device model is the 4.3 > default, upstream QEMU has its own native iscsi client built in. > Won't that 'just work'? (with libxl, perhaps not xl)Probably, but it will be much slower than blkback. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On Fri, Apr 19, 2013 at 08:50:16AM +0100, Ian Campbell wrote:> On Thu, 2013-04-18 at 19:09 +0100, Wei Liu wrote: > > On Tue, Apr 16, 2013 at 05:24:05PM +0100, George Dunlap wrote: > > > On 16/04/13 17:11, Wei Liu wrote: > > > > On Tue, Apr 16, 2013 at 04:20:09PM +0100, George Dunlap wrote: > > > >> On Tue, Apr 16, 2013 at 4:02 PM, Wei Liu <wei.liu2@citrix.com> wrote: > > > >>> On Tue, Apr 16, 2013 at 01:50:26PM +0100, George Dunlap wrote: > > > >>>> On Tue, Apr 16, 2013 at 1:22 PM, George Dunlap > > > >>>> <George.Dunlap@eu.citrix.com> wrote: > > > >>>> > > > >>>>> == Bugs => > > >>>>> > > > >>>>> * xl, compat mode, and older kernels > > > >>>>> owner: ? > > > >>>>> Many older 32-bit PV kernels that can run on a 64-bit hypervisor with > > > >>>>> xend do not work when started with xl. The following work-around seems to > > > >>>>> work: > > > >>>>> xl create -p lightning.cfg > > > >>>>> xenstore-write /local/domain/$(xl domid > > > >>>>> lightning)/device/vbd/51713/protocol x86_32-abi > > > >>>>> xl unpause lightning > > > >>>>> This node is normally written by the guest kernel, but for older kernels > > > >>>>> seems not to be. xend must have a work-around; port this work-around to xl. > > > >>> I played with Xend several years ago, I can try to have a look at this. > > > >>> > > > > Quick question, anyone has kernel image that''s needs this workaround? > > > > > > The original thread that started this is here: > > > > > > http://www.gossamer-threads.com/lists/xen/devel/258488?do=post_view_threaded > > > > > > It mentioned using Debian etch''s built-in 2.6.16.33-xen kernel. > > > > Now I''ve identified the problem, should I write a patch for it or should > > I wait till 4.4 window is open? > > Write a patch, we should at least consider it as a bug fix for 4.3. >No problem, getting to that. Wei.> Ian >