* libxl drivers for libvirt?
@ 2012-10-24 15:33 George Dunlap
2012-10-24 18:11 ` Jim Fehlig
0 siblings, 1 reply; 9+ messages in thread
From: George Dunlap @ 2012-10-24 15:33 UTC (permalink / raw)
To: Jim Fehlig; +Cc: Dario Faggioli, xen-devel
Hey Jim,
I was wondering if you or someone on your team could give me an idea
what the status of libxl support is in libvirt, particularly wrt
various releases?
I'm asking because I'm going to UDS next week to talk about the 13.04
release, and it would be good to get Xen 4.2 in; but that in part
depends on whether there will be libvirt support for 4.2 in whatever
version of libvirt they ship as well. I know Dario has been facing
the same kind of questions for Fedora 18.
It appears that libvirt 0.10.2 has limited support for the 4.1 libxl
driver; but:
* This doesn't include some core features, like live migration
* It won't compile against 4.2's libxl
Is that right?
So I guess it would be nice to know:
* What kind of Xen support is available in the most recent release
(0.10.2, I believe), both xend and libxl
* What kind of Xen support for libxl is in the libvirt development
branch, and do you have an idea when full support for 4.2 (at least,
including migration, suspend/resume, &c) might be available?
* Whether it would be easy for distros to backport 4.2 libxl support
to whatever their release is?
That would help us better advise distros whether to:
* Stick with Xen 4.1 for the next release
* Go with Xen 4.2 but suggest continuing to use xend if libvirt
support is wanted
* Go with Xen 4.2 and backport patches to make libvirt work with libxl
* Go with Xen 4.2 and expect that libxl support will show up without
too much effort
Obviously change is the only constant, so you can't predict with
perfect certainty; but if we have an idea what's most likely, we can
plan on that and then adjust based on what actually happens.
Thanks!
-George
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: libxl drivers for libvirt?
2012-10-24 15:33 libxl drivers for libvirt? George Dunlap
@ 2012-10-24 18:11 ` Jim Fehlig
2012-10-26 12:54 ` Ondřej Holeček
2012-10-26 13:03 ` George Dunlap
0 siblings, 2 replies; 9+ messages in thread
From: Jim Fehlig @ 2012-10-24 18:11 UTC (permalink / raw)
To: George Dunlap
Cc: Dario Faggioli, Bamvor Jian Zhang, Ondr(ej Holec(ek, Chun Yan Liu,
xen-devel
George Dunlap wrote:
> Hey Jim,
>
> I was wondering if you or someone on your team could give me an idea
> what the status of libxl support is in libvirt, particularly wrt
> various releases?
>
> I'm asking because I'm going to UDS next week to talk about the 13.04
> release, and it would be good to get Xen 4.2 in; but that in part
> depends on whether there will be libvirt support for 4.2 in whatever
> version of libvirt they ship as well. I know Dario has been facing
> the same kind of questions for Fedora 18.
>
> It appears that libvirt 0.10.2 has limited support for the 4.1 libxl
> driver; but:
> * This doesn't include some core features, like live migration
Right. Chunyan has some patches to implement migration against 4.1
libxl, but IIRC she is still investigating a bug. Chunyan, can you give
George an update on your libvirt libxl migration patches?
> * It won't compile against 4.2's libxl
Right again. Ondrej has been looking into this. Ondrej, do you have
any status to report? Any questions for the Xen folks wrt 4.1 vs 4.2 libxl?
> Is that right?
>
> So I guess it would be nice to know:
> * What kind of Xen support is available in the most recent release
> (0.10.2, I believe), both xend and libxl
I've provided a table below that lists all of the libvirt hypervisor
driver functions and their implementation status for qemu/kvm, legacy
xen, and libxl drivers.
> * What kind of Xen support for libxl is in the libvirt development
> branch, and do you have an idea when full support for 4.2 (at least,
> including migration, suspend/resume, &c) might be available?
Nothing has changed in git master over what is available in 0.10.2, but
we are now starting to pick up this work. Our priorities are to first
get the libxl driver compiling against 4.2 and all of the existing
functionality that works with 4.1 working with 4.2, followed by closing
the feature gap with the legacy xen driver, and finally closing the
feature gap with the qemu driver where it makes sense. This is
obviously quite a bit of work and any help would be appreciated :).
BTW, we don't have any motivation to add features to the 4.1 version of
the libvirt libxl driver. Bamvor recently sent a patchset to add
finer-grained locking to the libxl driver, but this code is independent
of underlying libxl version IMO
https://www.redhat.com/archives/libvir-list/2012-October/msg00503.html
> * Whether it would be easy for distros to backport 4.2 libxl support
> to whatever their release is?
Until we have patches to make the driver work with 4.2 libxl, I can't
speculate on the effort to backport to previous libvirt releases.
Regards,
Jim
> That would help us better advise distros whether to:
> * Stick with Xen 4.1 for the next release
> * Go with Xen 4.2 but suggest continuing to use xend if libvirt
> support is wanted
> * Go with Xen 4.2 and backport patches to make libvirt work with libxl
> * Go with Xen 4.2 and expect that libxl support will show up without
> too much effort
>
> Obviously change is the only constant, so you can't predict with
> perfect certainty; but if we have an idea what's most likely, we can
> plan on that and then adjust based on what actually happens.
>
> Thanks!
> -George
>
libvirt hypervisor driver funcs qemu xend libxl
-----------------------------------------------------------------
virDrvOpen | x | x | x |
virDrvClose | x | x | x |
virDrvDrvSupportsFeature | x | x | |
virDrvGetType | x | x | x |
virDrvGetVersion | x | x | x |
virDrvGetLibVersion | x | x | x |
virDrvGetHostname | x | x | x |
virDrvGetSysinfo | x | | |
virDrvGetMaxVcpus | x | x | x |
virDrvNodeGetInfo | x | x | x |
virDrvGetCapabilities | x | x | x |
virDrvListDomains | x | x | x |
virDrvNumOfDomains | x | x | x |
virDrvListAllDomains | x | | x |
virDrvDomainCreateXML | x | x | x |
virDrvDomainLookupByID | x | x | x |
virDrvDomainLookupByUUID | x | x | x |
virDrvDomainLookupByName | x | x | x |
virDrvDomainSuspend | x | x | x |
virDrvDomainResume | x | x | x |
virDrvDomainPMSuspendForDuration | x | | |
virDrvDomainPMWakeup | x | | |
virDrvDomainShutdown | x | x | x |
virDrvDomainShutdownFlags | x | x | x |
virDrvDomainReboot | x | x | x |
virDrvDomainReset | x | | |
virDrvDomainDestroy | x | x | x |
virDrvDomainDestroyFlags | x | x | x |
virDrvDomainGetOSType | x | x | x |
virDrvDomainGetHostname | | | |
virDrvDomainGetMaxMemory | x | x | x |
virDrvDomainSetMaxMemory | x | x | x |
virDrvDomainSetMemory | x | x | x |
virDrvDomainSetMemoryFlags | x | | x |
virDrvDomainSetMemoryParameters | x | | |
virDrvDomainGetMemoryParameters | x | | |
virDrvDomainSetNumaParameters | x | | |
virDrvDomainGetNumaParameters | x | | |
virDrvDomainSetBlkioParameters | x | | |
virDrvDomainGetBlkioParameters | x | | |
virDrvDomainGetInfo | x | x | x |
virDrvDomainGetState | x | x | x |
virDrvDomainGetControlInfo | x | | |
virDrvDomainSave | x | x | x |
virDrvDomainSaveFlags | x | x | x |
virDrvDomainRestore | x | x | x |
virDrvDomainRestoreFlags | x | x | x |
virDrvDomainSaveImageGetXMLDesc | x | | |
virDrvDomainSaveImageDefineXML | x | | |
virDrvDomainCoreDump | x | x | x |
virDrvDomainScreenshot | x | | |
virDrvDomainSetVcpus | x | x | x |
virDrvDomainSetVcpusFlags | x | x | x |
virDrvDomainGetVcpusFlags | x | x | x |
virDrvDomainPinVcpu | x | x | x |
virDrvDomainPinVcpuFlags | x | | |
virDrvDomainGetVcpuPinInfo | x | | |
virDrvDomainPinEmulator | x | | |
virDrvDomainGetEmulatorPinInfo | x | | |
virDrvDomainGetVcpus | x | x | x |
virDrvDomainGetMaxVcpus | x | x | |
virDrvDomainGetSecurityLabel | x | | |
virDrvDomainGetSecurityLabelList | x | | |
virDrvNodeGetSecurityModel | x | | |
virDrvDomainGetXMLDesc | x | x | x |
virDrvConnectDomainXMLFromNative | x | x | x |
virDrvConnectDomainXMLToNative | x | x | x |
virDrvListDefinedDomains | x | x | x |
virDrvNumOfDefinedDomains | x | x | x |
virDrvDomainCreate | x | x | x |
virDrvDomainCreateWithFlags | x | x | x |
virDrvDomainDefineXML | x | x | x |
virDrvDomainUndefine | x | x | x |
virDrvDomainUndefineFlags | x | x | x |
virDrvDomainAttachDevice | x | x | x |
virDrvDomainAttachDeviceFlags | x | x | x |
virDrvDomainDetachDevice | x | x | x |
virDrvDomainDetachDeviceFlags | x | x | x |
virDrvDomainUpdateDeviceFlags | x | x | x |
virDrvDomainGetAutostart | x | x | x |
virDrvDomainSetAutostart | x | x | x |
virDrvDomainGetSchedulerType | x | x | x |
virDrvDomainGetSchedulerParameters | x | x | x |
virDrvDomainGetSchedulerParametersFlags| x | x | x |
virDrvDomainSetSchedulerParameters | x | x | x |
virDrvDomainSetSchedulerParametersFlags| x | x | x |
virDrvDomainMigratePrepare | | x | |
virDrvDomainMigratePerform | x | x | |
virDrvDomainMigrateFinish | | x | |
virDrvDomainBlockResize | x | | |
virDrvDomainBlockStats | x | | |
virDrvDomainBlockStatsFlags | x | | |
virDrvDomainInterfaceStats | x | x | |
virDrvDomainSetInterfaceParameters | x | | |
virDrvDomainGetInterfaceParameters | x | | |
virDrvDomainMemoryStats | x | | |
virDrvDomainBlockPeek | x | x | |
virDrvDomainMemoryPeek | x | | |
virDrvDomainGetBlockInfo | x | | |
virDrvNodeGetCPUStats | x | | |
virDrvNodeGetMemoryStats | x | | |
virDrvNodeGetCellsFreeMemory | x | x | |
virDrvNodeGetFreeMemory | x | x | x |
virDrvDomainEventRegister | x | x | x |
virDrvDomainEventDeregister | x | x | x |
virDrvDomainMigratePrepare2 | x | | |
virDrvDomainMigrateFinish2 | x | | |
virDrvNodeDeviceDettach | x | x | |
virDrvNodeDeviceReAttach | x | x | |
virDrvNodeDeviceReset | x | x | |
virDrvDomainMigratePrepareTunnel | x | | |
virDrvConnectIsEncrypted | x | x | |
virDrvConnectIsSecure | x | x | |
virDrvDomainIsActive | x | x | x |
virDrvDomainIsPersistent | x | x | x |
virDrvDomainIsUpdated | x | x | x |
virDrvCompareCPU | x | | |
virDrvBaselineCPU | x | | |
virDrvDomainGetJobInfo | x | | |
virDrvDomainAbortJob | x | | |
virDrvDomainMigrateSetMaxDowntime | x | | |
virDrvDomainMigrateGetMaxSpeed | x | | |
virDrvDomainMigrateSetMaxSpeed | x | | |
virDrvDomainEventRegisterAny | x | | x |
virDrvDomainEventDeregisterAny | x | | x |
virDrvDomainManagedSave | x | | x |
virDrvDomainHasManagedSaveImage | x | | x |
virDrvDomainManagedSaveRemove | x | | x |
virDrvDomainSnapshotCreateXML | x | | |
virDrvDomainSnapshotGetXMLDesc | x | | |
virDrvDomainSnapshotNum | x | | |
virDrvDomainSnapshotListNames | x | | |
virDrvDomainListAllSnapshots | x | | |
virDrvDomainSnapshotNumChildren | x | | |
virDrvDomainSnapshotListChildrenNames | x | | |
virDrvDomainSnapshotListAllChildren | x | | |
virDrvDomainSnapshotLookupByName | x | | |
virDrvDomainHasCurrentSnapshot | x | | |
virDrvDomainSnapshotGetParent | x | | |
virDrvDomainSnapshotCurrent | x | | |
virDrvDomainSnapshotIsCurrent | x | | |
virDrvDomainSnapshotHasMetadata | x | | |
virDrvDomainRevertToSnapshot | x | | |
virDrvDomainSnapshotDelete | x | | |
virDrvDomainQemuMonitorCommand | x | | |
virDrvDomainQemuAttach | x | | |
virDrvDomainQemuAgentCommand | x | | |
virDrvDomainOpenConsole | x | x | |
virDrvDomainOpenGraphics | x | | |
virDrvDomainInjectNMI | x | | |
virDrvDomainMigrateBegin3 | x | | |
virDrvDomainMigratePrepare3 | x | | |
virDrvDomainMigratePrepareTunnel3 | x | | |
virDrvDomainMigratePerform3 | x | | |
virDrvDomainMigrateFinish3 | x | | |
virDrvDomainMigrateConfirm3 | x | | |
virDrvDomainSendKey | x | | |
virDrvDomainBlockJobAbort | x | | |
virDrvDomainGetBlockJobInfo | x | | |
virDrvDomainBlockJobSetSpeed | x | | |
virDrvDomainBlockPull | x | | |
virDrvDomainBlockRebase | x | | |
virDrvDomainBlockCommit | x | | |
virDrvSetKeepAlive | | | |
virDrvConnectIsAlive | x | | |
virDrvNodeSuspendForDuration | x | x | |
virDrvDomainSetBlockIoTune | x | | |
virDrvDomainGetBlockIoTune | x | | |
virDrvDomainGetCPUStats | x | | |
virDrvDomainGetDiskErrors | x | | |
virDrvDomainSetMetadata | x | | |
virDrvDomainGetMetadata | x | | |
virDrvNodeGetMemoryParameters | x | x | |
virDrvNodeSetMemoryParameters | x | x | |
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: libxl drivers for libvirt?
2012-10-24 18:11 ` Jim Fehlig
@ 2012-10-26 12:54 ` Ondřej Holeček
2012-10-26 13:12 ` Ian Campbell
2012-10-26 13:03 ` George Dunlap
1 sibling, 1 reply; 9+ messages in thread
From: Ondřej Holeček @ 2012-10-26 12:54 UTC (permalink / raw)
To: Jim Fehlig
Cc: George Dunlap, Dario Faggioli, Bamvor Jian Zhang, Chun Yan Liu,
xen-devel
Wednesday 24 of October 2012 12:11:37, Jim Fehlig:
> George Dunlap wrote:
> > Hey Jim,
> >
> > I was wondering if you or someone on your team could give me an idea
> > what the status of libxl support is in libvirt, particularly wrt
> > various releases?
> >
> > I'm asking because I'm going to UDS next week to talk about the 13.04
> > release, and it would be good to get Xen 4.2 in; but that in part
> > depends on whether there will be libvirt support for 4.2 in whatever
> > version of libvirt they ship as well. I know Dario has been facing
> > the same kind of questions for Fedora 18.
> >
> > It appears that libvirt 0.10.2 has limited support for the 4.1 libxl
> > driver; but:
> > * This doesn't include some core features, like live migration
>
> Right. Chunyan has some patches to implement migration against 4.1
> libxl, but IIRC she is still investigating a bug. Chunyan, can you give
> George an update on your libvirt libxl migration patches?
>
> > * It won't compile against 4.2's libxl
>
> Right again. Ondrej has been looking into this. Ondrej, do you have
> any status to report? Any questions for the Xen folks wrt 4.1 vs 4.2 libxl?
Hi,
I have libxl which compiles without errors under Xen 4.2, but I didn't test it much yet. I based my port on patch [1], but there
were numerous other issues like replaced libxl_cpumap by libxl_bitmap, added async operations, etc.
Right now I'm focusing on how to, if even possible, to support both 4.1 and 4.2 in same source files. Right now my libxl_compat.h is dangerously
growing.
I would definitely appreciate any detailed overview what and why changed between 4.1 and 4.2 libxl iface.
[1] http://lists.xen.org/archives/html/xen-devel/2012-05/msg00565.html
>
> > Is that right?
> >
> > So I guess it would be nice to know:
> > * What kind of Xen support is available in the most recent release
> > (0.10.2, I believe), both xend and libxl
>
> I've provided a table below that lists all of the libvirt hypervisor
> driver functions and their implementation status for qemu/kvm, legacy
> xen, and libxl drivers.
>
> > * What kind of Xen support for libxl is in the libvirt development
> > branch, and do you have an idea when full support for 4.2 (at least,
> > including migration, suspend/resume, &c) might be available?
>
> Nothing has changed in git master over what is available in 0.10.2, but
> we are now starting to pick up this work. Our priorities are to first
> get the libxl driver compiling against 4.2 and all of the existing
> functionality that works with 4.1 working with 4.2, followed by closing
> the feature gap with the legacy xen driver, and finally closing the
> feature gap with the qemu driver where it makes sense. This is
> obviously quite a bit of work and any help would be appreciated :).
>
> BTW, we don't have any motivation to add features to the 4.1 version of
> the libvirt libxl driver. Bamvor recently sent a patchset to add
> finer-grained locking to the libxl driver, but this code is independent
> of underlying libxl version IMO
>
> https://www.redhat.com/archives/libvir-list/2012-October/msg00503.html
>
>
> > * Whether it would be easy for distros to backport 4.2 libxl support
> > to whatever their release is?
>
> Until we have patches to make the driver work with 4.2 libxl, I can't
> speculate on the effort to backport to previous libvirt releases.
>
> Regards,
> Jim
>
> > That would help us better advise distros whether to:
> > * Stick with Xen 4.1 for the next release
> > * Go with Xen 4.2 but suggest continuing to use xend if libvirt
> > support is wanted
> > * Go with Xen 4.2 and backport patches to make libvirt work with libxl
> > * Go with Xen 4.2 and expect that libxl support will show up without
> > too much effort
> >
> > Obviously change is the only constant, so you can't predict with
> > perfect certainty; but if we have an idea what's most likely, we can
> > plan on that and then adjust based on what actually happens.
> >
> > Thanks!
> > -George
> >
>
> libvirt hypervisor driver funcs qemu xend libxl
> -----------------------------------------------------------------
> virDrvOpen | x | x | x |
> virDrvClose | x | x | x |
> virDrvDrvSupportsFeature | x | x | |
> virDrvGetType | x | x | x |
> virDrvGetVersion | x | x | x |
> virDrvGetLibVersion | x | x | x |
> virDrvGetHostname | x | x | x |
> virDrvGetSysinfo | x | | |
> virDrvGetMaxVcpus | x | x | x |
> virDrvNodeGetInfo | x | x | x |
> virDrvGetCapabilities | x | x | x |
> virDrvListDomains | x | x | x |
> virDrvNumOfDomains | x | x | x |
> virDrvListAllDomains | x | | x |
> virDrvDomainCreateXML | x | x | x |
> virDrvDomainLookupByID | x | x | x |
> virDrvDomainLookupByUUID | x | x | x |
> virDrvDomainLookupByName | x | x | x |
> virDrvDomainSuspend | x | x | x |
> virDrvDomainResume | x | x | x |
> virDrvDomainPMSuspendForDuration | x | | |
> virDrvDomainPMWakeup | x | | |
> virDrvDomainShutdown | x | x | x |
> virDrvDomainShutdownFlags | x | x | x |
> virDrvDomainReboot | x | x | x |
> virDrvDomainReset | x | | |
> virDrvDomainDestroy | x | x | x |
> virDrvDomainDestroyFlags | x | x | x |
> virDrvDomainGetOSType | x | x | x |
> virDrvDomainGetHostname | | | |
> virDrvDomainGetMaxMemory | x | x | x |
> virDrvDomainSetMaxMemory | x | x | x |
> virDrvDomainSetMemory | x | x | x |
> virDrvDomainSetMemoryFlags | x | | x |
> virDrvDomainSetMemoryParameters | x | | |
> virDrvDomainGetMemoryParameters | x | | |
> virDrvDomainSetNumaParameters | x | | |
> virDrvDomainGetNumaParameters | x | | |
> virDrvDomainSetBlkioParameters | x | | |
> virDrvDomainGetBlkioParameters | x | | |
> virDrvDomainGetInfo | x | x | x |
> virDrvDomainGetState | x | x | x |
> virDrvDomainGetControlInfo | x | | |
> virDrvDomainSave | x | x | x |
> virDrvDomainSaveFlags | x | x | x |
> virDrvDomainRestore | x | x | x |
> virDrvDomainRestoreFlags | x | x | x |
> virDrvDomainSaveImageGetXMLDesc | x | | |
> virDrvDomainSaveImageDefineXML | x | | |
> virDrvDomainCoreDump | x | x | x |
> virDrvDomainScreenshot | x | | |
> virDrvDomainSetVcpus | x | x | x |
> virDrvDomainSetVcpusFlags | x | x | x |
> virDrvDomainGetVcpusFlags | x | x | x |
> virDrvDomainPinVcpu | x | x | x |
> virDrvDomainPinVcpuFlags | x | | |
> virDrvDomainGetVcpuPinInfo | x | | |
> virDrvDomainPinEmulator | x | | |
> virDrvDomainGetEmulatorPinInfo | x | | |
> virDrvDomainGetVcpus | x | x | x |
> virDrvDomainGetMaxVcpus | x | x | |
> virDrvDomainGetSecurityLabel | x | | |
> virDrvDomainGetSecurityLabelList | x | | |
> virDrvNodeGetSecurityModel | x | | |
> virDrvDomainGetXMLDesc | x | x | x |
> virDrvConnectDomainXMLFromNative | x | x | x |
> virDrvConnectDomainXMLToNative | x | x | x |
> virDrvListDefinedDomains | x | x | x |
> virDrvNumOfDefinedDomains | x | x | x |
> virDrvDomainCreate | x | x | x |
> virDrvDomainCreateWithFlags | x | x | x |
> virDrvDomainDefineXML | x | x | x |
> virDrvDomainUndefine | x | x | x |
> virDrvDomainUndefineFlags | x | x | x |
> virDrvDomainAttachDevice | x | x | x |
> virDrvDomainAttachDeviceFlags | x | x | x |
> virDrvDomainDetachDevice | x | x | x |
> virDrvDomainDetachDeviceFlags | x | x | x |
> virDrvDomainUpdateDeviceFlags | x | x | x |
> virDrvDomainGetAutostart | x | x | x |
> virDrvDomainSetAutostart | x | x | x |
> virDrvDomainGetSchedulerType | x | x | x |
> virDrvDomainGetSchedulerParameters | x | x | x |
> virDrvDomainGetSchedulerParametersFlags| x | x | x |
> virDrvDomainSetSchedulerParameters | x | x | x |
> virDrvDomainSetSchedulerParametersFlags| x | x | x |
> virDrvDomainMigratePrepare | | x | |
> virDrvDomainMigratePerform | x | x | |
> virDrvDomainMigrateFinish | | x | |
> virDrvDomainBlockResize | x | | |
> virDrvDomainBlockStats | x | | |
> virDrvDomainBlockStatsFlags | x | | |
> virDrvDomainInterfaceStats | x | x | |
> virDrvDomainSetInterfaceParameters | x | | |
> virDrvDomainGetInterfaceParameters | x | | |
> virDrvDomainMemoryStats | x | | |
> virDrvDomainBlockPeek | x | x | |
> virDrvDomainMemoryPeek | x | | |
> virDrvDomainGetBlockInfo | x | | |
> virDrvNodeGetCPUStats | x | | |
> virDrvNodeGetMemoryStats | x | | |
> virDrvNodeGetCellsFreeMemory | x | x | |
> virDrvNodeGetFreeMemory | x | x | x |
> virDrvDomainEventRegister | x | x | x |
> virDrvDomainEventDeregister | x | x | x |
> virDrvDomainMigratePrepare2 | x | | |
> virDrvDomainMigrateFinish2 | x | | |
> virDrvNodeDeviceDettach | x | x | |
> virDrvNodeDeviceReAttach | x | x | |
> virDrvNodeDeviceReset | x | x | |
> virDrvDomainMigratePrepareTunnel | x | | |
> virDrvConnectIsEncrypted | x | x | |
> virDrvConnectIsSecure | x | x | |
> virDrvDomainIsActive | x | x | x |
> virDrvDomainIsPersistent | x | x | x |
> virDrvDomainIsUpdated | x | x | x |
> virDrvCompareCPU | x | | |
> virDrvBaselineCPU | x | | |
> virDrvDomainGetJobInfo | x | | |
> virDrvDomainAbortJob | x | | |
> virDrvDomainMigrateSetMaxDowntime | x | | |
> virDrvDomainMigrateGetMaxSpeed | x | | |
> virDrvDomainMigrateSetMaxSpeed | x | | |
> virDrvDomainEventRegisterAny | x | | x |
> virDrvDomainEventDeregisterAny | x | | x |
> virDrvDomainManagedSave | x | | x |
> virDrvDomainHasManagedSaveImage | x | | x |
> virDrvDomainManagedSaveRemove | x | | x |
> virDrvDomainSnapshotCreateXML | x | | |
> virDrvDomainSnapshotGetXMLDesc | x | | |
> virDrvDomainSnapshotNum | x | | |
> virDrvDomainSnapshotListNames | x | | |
> virDrvDomainListAllSnapshots | x | | |
> virDrvDomainSnapshotNumChildren | x | | |
> virDrvDomainSnapshotListChildrenNames | x | | |
> virDrvDomainSnapshotListAllChildren | x | | |
> virDrvDomainSnapshotLookupByName | x | | |
> virDrvDomainHasCurrentSnapshot | x | | |
> virDrvDomainSnapshotGetParent | x | | |
> virDrvDomainSnapshotCurrent | x | | |
> virDrvDomainSnapshotIsCurrent | x | | |
> virDrvDomainSnapshotHasMetadata | x | | |
> virDrvDomainRevertToSnapshot | x | | |
> virDrvDomainSnapshotDelete | x | | |
> virDrvDomainQemuMonitorCommand | x | | |
> virDrvDomainQemuAttach | x | | |
> virDrvDomainQemuAgentCommand | x | | |
> virDrvDomainOpenConsole | x | x | |
> virDrvDomainOpenGraphics | x | | |
> virDrvDomainInjectNMI | x | | |
> virDrvDomainMigrateBegin3 | x | | |
> virDrvDomainMigratePrepare3 | x | | |
> virDrvDomainMigratePrepareTunnel3 | x | | |
> virDrvDomainMigratePerform3 | x | | |
> virDrvDomainMigrateFinish3 | x | | |
> virDrvDomainMigrateConfirm3 | x | | |
> virDrvDomainSendKey | x | | |
> virDrvDomainBlockJobAbort | x | | |
> virDrvDomainGetBlockJobInfo | x | | |
> virDrvDomainBlockJobSetSpeed | x | | |
> virDrvDomainBlockPull | x | | |
> virDrvDomainBlockRebase | x | | |
> virDrvDomainBlockCommit | x | | |
> virDrvSetKeepAlive | | | |
> virDrvConnectIsAlive | x | | |
> virDrvNodeSuspendForDuration | x | x | |
> virDrvDomainSetBlockIoTune | x | | |
> virDrvDomainGetBlockIoTune | x | | |
> virDrvDomainGetCPUStats | x | | |
> virDrvDomainGetDiskErrors | x | | |
> virDrvDomainSetMetadata | x | | |
> virDrvDomainGetMetadata | x | | |
> virDrvNodeGetMemoryParameters | x | x | |
> virDrvNodeSetMemoryParameters | x | x | |
>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: libxl drivers for libvirt?
2012-10-24 18:11 ` Jim Fehlig
2012-10-26 12:54 ` Ondřej Holeček
@ 2012-10-26 13:03 ` George Dunlap
2012-10-26 13:18 ` Ian Campbell
2012-10-26 14:00 ` Ian Jackson
1 sibling, 2 replies; 9+ messages in thread
From: George Dunlap @ 2012-10-26 13:03 UTC (permalink / raw)
To: Jim Fehlig
Cc: Ian Campbell, Dario Faggioli, Ian Jackson, Chun Yan Liu,
xen-devel@lists.xen.org, Ondrej Holecek, Bamvor Jian Zhang
On 24/10/12 19:11, Jim Fehlig wrote:
>> * What kind of Xen support for libxl is in the libvirt development
>> branch, and do you have an idea when full support for 4.2 (at least,
>> including migration, suspend/resume, &c) might be available?
> Nothing has changed in git master over what is available in 0.10.2, but
> we are now starting to pick up this work. Our priorities are to first
> get the libxl driver compiling against 4.2 and all of the existing
> functionality that works with 4.1 working with 4.2, followed by closing
> the feature gap with the legacy xen driver, and finally closing the
> feature gap with the qemu driver where it makes sense. This is
> obviously quite a bit of work and any help would be appreciated :).
>
> BTW, we don't have any motivation to add features to the 4.1 version of
> the libvirt libxl driver.
That sounds like a good plan. For 4.1, xend is still the default
toolstack, and libxl is a "tech preview"; for 4.2, xl is the default
toolstack, and (if I understand correctly) we're officially going to be
supporting the libxl interface in a backwards-compatible way from here
forward.
It seems to me that if you have trouble supporting both libxl 4.2 and
libxl 4.1, that it might be better just to drop 4.1 support and focus on
4.2. Ian Campbell / Jackson: Thoughts?
-George
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: libxl drivers for libvirt?
2012-10-26 12:54 ` Ondřej Holeček
@ 2012-10-26 13:12 ` Ian Campbell
0 siblings, 0 replies; 9+ messages in thread
From: Ian Campbell @ 2012-10-26 13:12 UTC (permalink / raw)
To: Ondřej Holeček
Cc: George Dunlap, Dario Faggioli, Chun Yan Liu,
xen-devel@lists.xen.org, Jim Fehlig, Bamvor Jian Zhang
On Fri, 2012-10-26 at 13:54 +0100, Ondřej Holeček wrote:
> I would definitely appreciate any detailed overview what and why
> changed between 4.1 and 4.2 libxl iface.
A whole tonne of stuff I'm afraid :-/
The bigger things which spring to mind are:
* The event handling subsystem. This was designed specifically
with libvirt in mind so I hope they work well for you.
* Making APIs capable of being called asynchronously where
necessary. This should benefit toolstacks with a daemon which
manages multiple domains.
* Fixes to the handling of forking and signals etc. These are
problematic to use in a library but we think we've come up with
a solution which works. Ian J blogged about this [1].
* Tweaks to the API to make them more consistent and symmetric,
mostly to file some of the rought edges/gotchas us before
calling the API stable and to give us something which we were
happy to support going forward.
The upside is that in 4.2 we have a libxl API which we are committed to
maintaining in a stable / backwards compatible manner, as described in
libxl.h[0].
Ian.
[0]
http://xenbits.xen.org/hg/xen-unstable.hg/file/tip/tools/libxl/libxl.h#l16
[1]
http://blog.xen.org/index.php/2012/05/22/libxl-event-api-improvements/
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: libxl drivers for libvirt?
2012-10-26 13:03 ` George Dunlap
@ 2012-10-26 13:18 ` Ian Campbell
2012-10-29 15:55 ` Jim Fehlig
2012-10-26 14:00 ` Ian Jackson
1 sibling, 1 reply; 9+ messages in thread
From: Ian Campbell @ 2012-10-26 13:18 UTC (permalink / raw)
To: George Dunlap
Cc: Dario Faggioli, Ian Jackson, Chun Yan Liu,
xen-devel@lists.xen.org, Jim Fehlig, Ondrej Holecek,
Bamvor Jian Zhang
On Fri, 2012-10-26 at 14:03 +0100, George Dunlap wrote:
> On 24/10/12 19:11, Jim Fehlig wrote:
> >> * What kind of Xen support for libxl is in the libvirt development
> >> branch, and do you have an idea when full support for 4.2 (at least,
> >> including migration, suspend/resume, &c) might be available?
> > Nothing has changed in git master over what is available in 0.10.2, but
> > we are now starting to pick up this work. Our priorities are to first
> > get the libxl driver compiling against 4.2 and all of the existing
> > functionality that works with 4.1 working with 4.2, followed by closing
> > the feature gap with the legacy xen driver, and finally closing the
> > feature gap with the qemu driver where it makes sense. This is
> > obviously quite a bit of work and any help would be appreciated :).
> >
> > BTW, we don't have any motivation to add features to the 4.1 version of
> > the libvirt libxl driver.
>
> That sounds like a good plan. For 4.1, xend is still the default
> toolstack, and libxl is a "tech preview"; for 4.2, xl is the default
> toolstack, and (if I understand correctly) we're officially going to be
> supporting the libxl interface in a backwards-compatible way from here
> forward.
>
> It seems to me that if you have trouble supporting both libxl 4.2 and
> libxl 4.1, that it might be better just to drop 4.1 support and focus on
> 4.2. Ian Campbell / Jackson: Thoughts?
That's what I would do if I were them ;-)
Another option would be to fork into 4.1 and 4.2+ versions and to stop
adding new stuff to the 4.1 copy. That has its own downsides though.
Ian.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: libxl drivers for libvirt?
2012-10-26 13:03 ` George Dunlap
2012-10-26 13:18 ` Ian Campbell
@ 2012-10-26 14:00 ` Ian Jackson
1 sibling, 0 replies; 9+ messages in thread
From: Ian Jackson @ 2012-10-26 14:00 UTC (permalink / raw)
To: George Dunlap
Cc: Ian Campbell, Dario Faggioli, Chun Yan Liu,
xen-devel@lists.xen.org, Jim Fehlig, Ondrej Holecek,
Bamvor Jian Zhang
George Dunlap writes ("Re: [Xen-devel] libxl drivers for libvirt?"):
> That sounds like a good plan. For 4.1, xend is still the default
> toolstack, and libxl is a "tech preview"; for 4.2, xl is the default
> toolstack, and (if I understand correctly) we're officially going to be
> supporting the libxl interface in a backwards-compatible way from here
> forward.
Yes.
> It seems to me that if you have trouble supporting both libxl 4.2 and
> libxl 4.1, that it might be better just to drop 4.1 support and focus on
> 4.2. Ian Campbell / Jackson: Thoughts?
Yes, I agree.
Ian.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: libxl drivers for libvirt?
2012-10-26 13:18 ` Ian Campbell
@ 2012-10-29 15:55 ` Jim Fehlig
2012-10-29 16:05 ` [libvirt] " Daniel P. Berrange
0 siblings, 1 reply; 9+ messages in thread
From: Jim Fehlig @ 2012-10-29 15:55 UTC (permalink / raw)
To: Ian Campbell
Cc: George Dunlap, Dario Faggioli, Ian Jackson, Chun Yan Liu,
xen-devel@lists.xen.org, LibVir, Ondrej Holecek,
Bamvor Jian Zhang
Ian Campbell wrote:
> On Fri, 2012-10-26 at 14:03 +0100, George Dunlap wrote:
>
>> On 24/10/12 19:11, Jim Fehlig wrote:
>>
>>>> * What kind of Xen support for libxl is in the libvirt development
>>>> branch, and do you have an idea when full support for 4.2 (at least,
>>>> including migration, suspend/resume, &c) might be available?
>>>>
>>> Nothing has changed in git master over what is available in 0.10.2, but
>>> we are now starting to pick up this work. Our priorities are to first
>>> get the libxl driver compiling against 4.2 and all of the existing
>>> functionality that works with 4.1 working with 4.2, followed by closing
>>> the feature gap with the legacy xen driver, and finally closing the
>>> feature gap with the qemu driver where it makes sense. This is
>>> obviously quite a bit of work and any help would be appreciated :).
>>>
>>> BTW, we don't have any motivation to add features to the 4.1 version of
>>> the libvirt libxl driver.
>>>
>> That sounds like a good plan. For 4.1, xend is still the default
>> toolstack, and libxl is a "tech preview"; for 4.2, xl is the default
>> toolstack, and (if I understand correctly) we're officially going to be
>> supporting the libxl interface in a backwards-compatible way from here
>> forward.
>>
>> It seems to me that if you have trouble supporting both libxl 4.2 and
>> libxl 4.1, that it might be better just to drop 4.1 support and focus on
>> 4.2. Ian Campbell / Jackson: Thoughts?
>>
CC'ing libvirt community to get their input.
>
> That's what I would do if I were them ;-)
>
I tend to agree that this might be the best approach. The libxl in Xen
4.1 is essentially a one-off and I question whether we should pollute
the libvirt libxl driver code with support for a dead, tech preview
interface. Xend is still the primary toolstack in Xen 4.1.x, and
libvirt has a stable, functional driver for this toolstack that can
(should) be used in Xen 4.1.x deployments.
Is anyone using the libvirt libxl driver with Xen 4.1 for anything other
than development or experimentation?
> Another option would be to fork into 4.1 and 4.2+ versions and to stop
> adding new stuff to the 4.1 copy. That has its own downsides though.
>
I'd like to hear what the libvirt community thinks about only supporting
Xen >= 4.2 in the libxl driver.
Regards,
Jim
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [libvirt] libxl drivers for libvirt?
2012-10-29 15:55 ` Jim Fehlig
@ 2012-10-29 16:05 ` Daniel P. Berrange
0 siblings, 0 replies; 9+ messages in thread
From: Daniel P. Berrange @ 2012-10-29 16:05 UTC (permalink / raw)
To: Jim Fehlig
Cc: Ian Campbell, George Dunlap, Dario Faggioli, Ian Jackson,
xen-devel@lists.xen.org, LibVir, Bamvor Jian Zhang
On Mon, Oct 29, 2012 at 09:55:28AM -0600, Jim Fehlig wrote:
> Ian Campbell wrote:
> > On Fri, 2012-10-26 at 14:03 +0100, George Dunlap wrote:
> >
> >> On 24/10/12 19:11, Jim Fehlig wrote:
> >>
> >>>> * What kind of Xen support for libxl is in the libvirt development
> >>>> branch, and do you have an idea when full support for 4.2 (at least,
> >>>> including migration, suspend/resume, &c) might be available?
> >>>>
> >>> Nothing has changed in git master over what is available in 0.10.2, but
> >>> we are now starting to pick up this work. Our priorities are to first
> >>> get the libxl driver compiling against 4.2 and all of the existing
> >>> functionality that works with 4.1 working with 4.2, followed by closing
> >>> the feature gap with the legacy xen driver, and finally closing the
> >>> feature gap with the qemu driver where it makes sense. This is
> >>> obviously quite a bit of work and any help would be appreciated :).
> >>>
> >>> BTW, we don't have any motivation to add features to the 4.1 version of
> >>> the libvirt libxl driver.
> >>>
> >> That sounds like a good plan. For 4.1, xend is still the default
> >> toolstack, and libxl is a "tech preview"; for 4.2, xl is the default
> >> toolstack, and (if I understand correctly) we're officially going to be
> >> supporting the libxl interface in a backwards-compatible way from here
> >> forward.
> >>
> >> It seems to me that if you have trouble supporting both libxl 4.2 and
> >> libxl 4.1, that it might be better just to drop 4.1 support and focus on
> >> 4.2. Ian Campbell / Jackson: Thoughts?
> >>
>
> CC'ing libvirt community to get their input.
>
> >
> > That's what I would do if I were them ;-)
> >
>
> I tend to agree that this might be the best approach. The libxl in Xen
> 4.1 is essentially a one-off and I question whether we should pollute
> the libvirt libxl driver code with support for a dead, tech preview
> interface. Xend is still the primary toolstack in Xen 4.1.x, and
> libvirt has a stable, functional driver for this toolstack that can
> (should) be used in Xen 4.1.x deployments.
>
> Is anyone using the libvirt libxl driver with Xen 4.1 for anything other
> than development or experimentation?
>
> > Another option would be to fork into 4.1 and 4.2+ versions and to stop
> > adding new stuff to the 4.1 copy. That has its own downsides though.
> >
>
> I'd like to hear what the libvirt community thinks about only supporting
> Xen >= 4.2 in the libxl driver.
Given that libxl was "tech preview" in Xen 4.1, I'm fine with any
proposal to have libvirt libxl only work with Xen 4.2, if that's
what you feel is the most appropriate plan. You're the primary
maintainer if this libvirt driver, so I'll defer to your technical
knowledge here on the supportability issues here.
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2012-10-29 16:05 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-10-24 15:33 libxl drivers for libvirt? George Dunlap
2012-10-24 18:11 ` Jim Fehlig
2012-10-26 12:54 ` Ondřej Holeček
2012-10-26 13:12 ` Ian Campbell
2012-10-26 13:03 ` George Dunlap
2012-10-26 13:18 ` Ian Campbell
2012-10-29 15:55 ` Jim Fehlig
2012-10-29 16:05 ` [libvirt] " Daniel P. Berrange
2012-10-26 14:00 ` Ian Jackson
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).