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