libvirt/src/libvirt_private.syms

724 lines
15 KiB
Plaintext
Raw Normal View History

#
# General private symbols. Add symbols here, and see Makefile.am for
# more details.
#
# buf.h
virBufferVSprintf;
virBufferEscapeString;
virBufferAdd;
virBufferAddChar;
virBufferContentAndReset;
virBufferError;
virBufferURIEncodeString;
virBufferFreeAndReset;
# caps.h
virCapabilitiesAddGuest;
virCapabilitiesAddGuestDomain;
virCapabilitiesAddGuestFeature;
virCapabilitiesAddHostMigrateTransport;
virCapabilitiesAddHostNUMACell;
virCapabilitiesAddHostFeature;
virCapabilitiesDefaultGuestArch;
virCapabilitiesDefaultGuestEmulator;
virCapabilitiesDefaultGuestMachine;
virCapabilitiesFormatXML;
virCapabilitiesFree;
virCapabilitiesFreeNUMAInfo;
virCapabilitiesNew;
virCapabilitiesSetMacPrefix;
virCapabilitiesGenerateMac;
virCapabilitiesSetEmulatorRequired;
virCapabilitiesIsEmulatorRequired;
virCapabilitiesAllocMachines;
virCapabilitiesFreeMachines;
virCapabilitiesSetHostCPU;
# conf.h
virConfNew;
virConfReadFile;
virConfReadMem;
virConfFree;
virConfFreeValue;
virConfGetValue;
virConfSetValue;
virConfWriteFile;
virConfWriteMem;
# cgroup.h
virCgroupForDomain;
virCgroupForDriver;
virCgroupRemove;
virCgroupFree;
virCgroupAddTask;
virCgroupSetMemory;
virCgroupGetMemoryUsage;
virCgroupSetCpuShares;
virCgroupGetCpuShares;
virCgroupDenyDevicePath;
virCgroupAllowDevicePath;
virCgroupDenyAllDevices;
virCgroupAllowDeviceMajor;
virCgroupControllerTypeToString;
virCgroupControllerTypeFromString;
virCgroupGetCpuacctUsage;
virCgroupGetFreezerState;
virCgroupSetFreezerState;
Adds CPU selection infrastructure Each driver supporting CPU selection must fill in host CPU capabilities. When filling them, drivers for hypervisors running on the same node as libvirtd can use cpuNodeData() to obtain raw CPU data. Other drivers, such as VMware, need to implement their own way of getting such data. Raw data can be decoded into virCPUDefPtr using cpuDecode() function. When implementing virConnectCompareCPU(), a hypervisor driver can just call cpuCompareXML() function with host CPU capabilities. For each guest for which a driver supports selecting CPU models, it must set the appropriate feature in guest's capabilities: virCapabilitiesAddGuestFeature(guest, "cpuselection", 1, 0) Actions needed when a domain is being created depend on whether the hypervisor understands raw CPU data (currently CPUID for i686, x86_64 architectures) or symbolic names has to be used. Typical use by hypervisors which prefer CPUID (such as VMware and Xen): - convert guest CPU configuration from domain's XML into a set of raw data structures each representing one of the feature policies: cpuEncode(conn, architecture, guest_cpu_config, &forced_data, &required_data, &optional_data, &disabled_data, &forbidden_data) - create a mask or whatever the hypervisor expects to see and pass it to the hypervisor Typical use by hypervisors with symbolic model names (such as QEMU): - get raw CPU data for a computed guest CPU: cpuGuestData(conn, host_cpu, guest_cpu_config, &data) - decode raw data into virCPUDefPtr with a possible restriction on allowed model names: cpuDecode(conn, guest, data, n_allowed_models, allowed_models) - pass guest->model and guest->features to the hypervisor * src/cpu/cpu.c src/cpu/cpu.h src/cpu/cpu_generic.c src/cpu/cpu_generic.h src/cpu/cpu_map.c src/cpu/cpu_map.h src/cpu/cpu_x86.c src/cpu/cpu_x86.h src/cpu/cpu_x86_data.h * configure.in: check for CPUID instruction * src/Makefile.am: glue the new files in * src/libvirt_private.syms: add new private symbols * po/POTFILES.in: add new cpu files containing translatable strings
2009-12-18 15:02:11 +00:00
# cpu.h
cpuBaseline;
cpuBaselineXML;
Adds CPU selection infrastructure Each driver supporting CPU selection must fill in host CPU capabilities. When filling them, drivers for hypervisors running on the same node as libvirtd can use cpuNodeData() to obtain raw CPU data. Other drivers, such as VMware, need to implement their own way of getting such data. Raw data can be decoded into virCPUDefPtr using cpuDecode() function. When implementing virConnectCompareCPU(), a hypervisor driver can just call cpuCompareXML() function with host CPU capabilities. For each guest for which a driver supports selecting CPU models, it must set the appropriate feature in guest's capabilities: virCapabilitiesAddGuestFeature(guest, "cpuselection", 1, 0) Actions needed when a domain is being created depend on whether the hypervisor understands raw CPU data (currently CPUID for i686, x86_64 architectures) or symbolic names has to be used. Typical use by hypervisors which prefer CPUID (such as VMware and Xen): - convert guest CPU configuration from domain's XML into a set of raw data structures each representing one of the feature policies: cpuEncode(conn, architecture, guest_cpu_config, &forced_data, &required_data, &optional_data, &disabled_data, &forbidden_data) - create a mask or whatever the hypervisor expects to see and pass it to the hypervisor Typical use by hypervisors with symbolic model names (such as QEMU): - get raw CPU data for a computed guest CPU: cpuGuestData(conn, host_cpu, guest_cpu_config, &data) - decode raw data into virCPUDefPtr with a possible restriction on allowed model names: cpuDecode(conn, guest, data, n_allowed_models, allowed_models) - pass guest->model and guest->features to the hypervisor * src/cpu/cpu.c src/cpu/cpu.h src/cpu/cpu_generic.c src/cpu/cpu_generic.h src/cpu/cpu_map.c src/cpu/cpu_map.h src/cpu/cpu_x86.c src/cpu/cpu_x86.h src/cpu/cpu_x86_data.h * configure.in: check for CPUID instruction * src/Makefile.am: glue the new files in * src/libvirt_private.syms: add new private symbols * po/POTFILES.in: add new cpu files containing translatable strings
2009-12-18 15:02:11 +00:00
cpuCompare;
cpuCompareXML;
cpuDataFree;
cpuDecode;
cpuEncode;
cpuGuestData;
cpuNodeData;
cpuUpdate;
Adds CPU selection infrastructure Each driver supporting CPU selection must fill in host CPU capabilities. When filling them, drivers for hypervisors running on the same node as libvirtd can use cpuNodeData() to obtain raw CPU data. Other drivers, such as VMware, need to implement their own way of getting such data. Raw data can be decoded into virCPUDefPtr using cpuDecode() function. When implementing virConnectCompareCPU(), a hypervisor driver can just call cpuCompareXML() function with host CPU capabilities. For each guest for which a driver supports selecting CPU models, it must set the appropriate feature in guest's capabilities: virCapabilitiesAddGuestFeature(guest, "cpuselection", 1, 0) Actions needed when a domain is being created depend on whether the hypervisor understands raw CPU data (currently CPUID for i686, x86_64 architectures) or symbolic names has to be used. Typical use by hypervisors which prefer CPUID (such as VMware and Xen): - convert guest CPU configuration from domain's XML into a set of raw data structures each representing one of the feature policies: cpuEncode(conn, architecture, guest_cpu_config, &forced_data, &required_data, &optional_data, &disabled_data, &forbidden_data) - create a mask or whatever the hypervisor expects to see and pass it to the hypervisor Typical use by hypervisors with symbolic model names (such as QEMU): - get raw CPU data for a computed guest CPU: cpuGuestData(conn, host_cpu, guest_cpu_config, &data) - decode raw data into virCPUDefPtr with a possible restriction on allowed model names: cpuDecode(conn, guest, data, n_allowed_models, allowed_models) - pass guest->model and guest->features to the hypervisor * src/cpu/cpu.c src/cpu/cpu.h src/cpu/cpu_generic.c src/cpu/cpu_generic.h src/cpu/cpu_map.c src/cpu/cpu_map.h src/cpu/cpu_x86.c src/cpu/cpu_x86.h src/cpu/cpu_x86_data.h * configure.in: check for CPUID instruction * src/Makefile.am: glue the new files in * src/libvirt_private.syms: add new private symbols * po/POTFILES.in: add new cpu files containing translatable strings
2009-12-18 15:02:11 +00:00
# cpu_conf.h
virCPUDefFree;
virCPUDefParseXML;
virCPUDefFormat;
virCPUDefFormatBuf;
virCPUDefAddFeature;
virCPUDefCopy;
# datatypes.h
virGetDomain;
virGetInterface;
virGetNetwork;
virGetStoragePool;
virGetStorageVol;
virGetSecret;
virUnrefStorageVol;
virGetNodeDevice;
virUnrefDomain;
virUnrefConnect;
virUnrefSecret;
virGetStream;
virUnrefStream;
virGetNWFilter;
virUnrefNWFilter;
virGetDomainSnapshot;
# domain_conf.h
virDiskNameToBusDeviceIndex;
virDiskNameToIndex;
virDomainAssignDef;
virDomainConfigFile;
virDomainCpuSetFormat;
virDomainCpuSetParse;
virDomainChrDefFree;
virDomainChrTypeFromString;
virDomainChrTypeToString;
virDomainDefFormat;
virDomainDefFree;
virDomainDefParseFile;
virDomainDefParseNode;
virDomainDefParseString;
virDomainDeleteConfig;
virDomainDeviceDefFree;
virDomainDeviceDefParse;
virDomainDeviceTypeToString;
virDomainDiskBusTypeToString;
virDomainDiskDefFree;
virDomainDiskDeviceTypeToString;
virDomainDiskInsert;
virDomainDiskInsertPreAlloced;
virDomainDiskDefAssignAddress;
virDomainControllerInsert;
virDomainControllerInsertPreAlloced;
virDomainFindByID;
virDomainFindByName;
virDomainFindByUUID;
virDomainGetRootFilesystem;
virDomainGraphicsTypeFromString;
virDomainGraphicsTypeToString;
virDomainGraphicsDefFree;
2009-04-24 12:19:00 +00:00
virDomainHostdevDefFree;
virDomainHostdevModeTypeToString;
virDomainHostdevSubsysTypeToString;
virDomainInputDefFree;
virDomainLifecycleTypeFromString;
virDomainLifecycleTypeToString;
virDomainLoadAllConfigs;
virDomainNetDefFree;
virDomainNetTypeToString;
virDomainRemoveInactive;
virDomainSaveXML;
virDomainSaveConfig;
virDomainSaveStatus;
virDomainSoundDefFree;
virDomainSoundModelTypeFromString;
virDomainSoundModelTypeToString;
virDomainWatchdogModelTypeFromString;
virDomainWatchdogModelTypeToString;
virDomainWatchdogActionTypeFromString;
virDomainWatchdogActionTypeToString;
virDomainVideoDefFree;
virDomainVideoTypeToString;
virDomainVideoTypeFromString;
virDomainVideoDefaultRAM;
virDomainVideoDefaultType;
virDomainVirtTypeToString;
virDomainFSDefFree;
virDomainObjLock;
virDomainObjUnlock;
2009-01-19 21:06:26 +00:00
virDomainStateTypeToString;
virDomainStateTypeFromString;
virDomainObjIsDuplicate;
Convert virDomainObjListPtr to use a hash of domain objects The current virDomainObjListPtr object stores domain objects in an array. This means that to find a particular objects requires O(n) time, and more critically acquiring O(n) mutex locks. The new impl replaces the array with a virHashTable, keyed off UUID. Finding a object based on UUID is now O(1) time, and only requires a single mutex lock. Finding by name/id is unchanged in complexity. In changing this, all code which iterates over the array had to be updated to use a hash table iterator function callback. Several of the functions which were identically duplicating across all drivers were pulled into domain_conf.c * src/conf/domain_conf.h, src/conf/domain_conf.c: Change virDomainObjListPtr to use virHashTable. Add a initializer method virDomainObjListInit, and rename virDomainObjListFree to virDomainObjListDeinit, since its not actually freeing the container, only its contents. Also add some convenient methods virDomainObjListGetInactiveNames, virDomainObjListGetActiveIDs and virDomainObjListNumOfDomains which can be used to implement the correspondingly named public API entry points in drivers * src/libvirt_private.syms: Export new methods from domain_conf.h * src/lxc/lxc_driver.c, src/opennebula/one_driver.c, src/openvz/openvz_conf.c, src/openvz/openvz_driver.c, src/qemu/qemu_driver.c, src/test/test_driver.c, src/uml/uml_driver.c, src/vbox/vbox_tmpl.c: Update all code to deal with hash tables instead of arrays for domains
2009-10-09 11:33:51 +00:00
virDomainObjListGetInactiveNames;
virDomainObjListGetActiveIDs;
virDomainObjListNumOfDomains;
virDomainObjListInit;
virDomainObjListDeinit;
virDomainObjRef;
virDomainObjUnref;
virDomainDeviceAddressIsValid;
virDomainDevicePCIAddressIsValid;
virDomainDeviceInfoIsSet;
virDomainControllerTypeToString;
virDomainControllerDefFree;
virDomainDeviceAddressTypeToString;
virDomainDefAddImplicitControllers;
virDomainDefClearPCIAddresses;
virDomainDefClearDeviceAliases;
virDomainDeviceInfoIterate;
virDomainClockOffsetTypeToString;
virDomainClockOffsetTypeFromString;
virDomainDiskErrorPolicyTypeToString;
virDomainTimerNameTypeToString;
virDomainTimerNameTypeFromString;
virDomainTimerTrackTypeToString;
virDomainTimerTrackTypeFromString;
virDomainTimerTickpolicyTypeToString;
virDomainTimerTickpolicyTypeFromString;
virDomainTimerModeTypeToString;
virDomainTimerModeTypeFromString;
virDomainSnapshotObjListGetNames;
virDomainSnapshotObjListNum;
virDomainSnapshotFindByName;
virDomainSnapshotObjListRemove;
virDomainSnapshotHasChildren;
virDomainSnapshotObjUnref;
virDomainSnapshotDefParseString;
virDomainSnapshotDefFormat;
virDomainSnapshotAssignDef;
# domain_event.h
virDomainEventCallbackListAdd;
virDomainEventCallbackListAddID;
virDomainEventCallbackListFree;
virDomainEventCallbackListRemove;
virDomainEventCallbackListRemoveID;
virDomainEventCallbackListRemoveConn;
virDomainEventCallbackListMarkDelete;
virDomainEventCallbackListMarkDeleteID;
virDomainEventCallbackListPurgeMarked;
virDomainEventCallbackListCount;
virDomainEventCallbackListCountID;
virDomainEventCallbackListEventID;
virDomainEventQueueNew;
virDomainEventQueueFree;
virDomainEventQueuePop;
virDomainEventQueuePush;
virDomainEventNew;
virDomainEventNewFromDom;
virDomainEventNewFromObj;
virDomainEventNewFromDef;
virDomainEventRebootNewFromDom;
virDomainEventRebootNewFromObj;
virDomainEventRTCChangeNewFromDom;
virDomainEventRTCChangeNewFromObj;
virDomainEventWatchdogNewFromDom;
virDomainEventWatchdogNewFromObj;
Add support for an explicit IO error event This introduces a new event type VIR_DOMAIN_EVENT_ID_IO_ERROR This event includes the action that is about to be taken as a result of the watchdog triggering typedef enum { VIR_DOMAIN_EVENT_IO_ERROR_NONE = 0, VIR_DOMAIN_EVENT_IO_ERROR_PAUSE, VIR_DOMAIN_EVENT_IO_ERROR_REPORT, } virDomainEventIOErrorAction; In addition it has the source path of the disk that had the error and its unique device alias. It does not include the target device name (/dev/sda), since this would preclude triggering IO errors from other file backed devices (eg serial ports connected to a file) Thus there is a new callback definition for this event type typedef void (*virConnectDomainEventIOErrorCallback)(virConnectPtr conn, virDomainPtr dom, const char *srcPath, const char *devAlias, int action, void *opaque); This is currently wired up to the QEMU block IO error events * daemon/remote.c: Dispatch IO error events to client * examples/domain-events/events-c/event-test.c: Watch for IO error events * include/libvirt/libvirt.h.in: Define new IO error event ID and callback signature * src/conf/domain_event.c, src/conf/domain_event.h, src/libvirt_private.syms: Extend API to handle IO error events * src/qemu/qemu_driver.c: Connect to the QEMU monitor event for block IO errors and emit a libvirt IO error event * src/remote/remote_driver.c: Receive and dispatch IO error events to application * src/remote/remote_protocol.x: Wire protocol definition for IO error events * src/qemu/qemu_monitor.c, src/qemu/qemu_monitor.h, src/qemu/qemu_monitor_json.c: Watch for BLOCK_IO_ERROR event from QEMU monitor
2010-03-18 19:37:44 +00:00
virDomainEventIOErrorNewFromDom;
virDomainEventIOErrorNewFromObj;
Add domain events for graphics network clients This introduces a new event type VIR_DOMAIN_EVENT_ID_GRAPHICS The same event can be emitted in 3 scenarios typedef enum { VIR_DOMAIN_EVENT_GRAPHICS_CONNECT = 0, VIR_DOMAIN_EVENT_GRAPHICS_INITIALIZE, VIR_DOMAIN_EVENT_GRAPHICS_DISCONNECT, } virDomainEventGraphicsPhase; Connect/disconnect are triggered at socket accept/close. The initialize phase is immediately after the protocol setup and authentication has completed. ie when the client is authorized and about to start interacting with the graphical desktop This event comes with *a lot* of potential information - IP address, port & address family of client - IP address, port & address family of server - Authentication scheme (arbitrary string) - Authenticated subject identity. A subject may have multiple identities with some authentication schemes. For example, vencrypt+sasl results in a x509dname and saslUsername identities. This results in a very complicated callback :-( typedef enum { VIR_DOMAIN_EVENT_GRAPHICS_ADDRESS_IPV4, VIR_DOMAIN_EVENT_GRAPHICS_ADDRESS_IPV6, } virDomainEventGraphicsAddressType; struct _virDomainEventGraphicsAddress { int family; const char *node; const char *service; }; typedef struct _virDomainEventGraphicsAddress virDomainEventGraphicsAddress; typedef virDomainEventGraphicsAddress *virDomainEventGraphicsAddressPtr; struct _virDomainEventGraphicsSubject { int nidentity; struct { const char *type; const char *name; } *identities; }; typedef struct _virDomainEventGraphicsSubject virDomainEventGraphicsSubject; typedef virDomainEventGraphicsSubject *virDomainEventGraphicsSubjectPtr; typedef void (*virConnectDomainEventGraphicsCallback)(virConnectPtr conn, virDomainPtr dom, int phase, virDomainEventGraphicsAddressPtr local, virDomainEventGraphicsAddressPtr remote, const char *authScheme, virDomainEventGraphicsSubjectPtr subject, void *opaque); The wire protocol is similarly complex struct remote_domain_event_graphics_address { int family; remote_nonnull_string node; remote_nonnull_string service; }; const REMOTE_DOMAIN_EVENT_GRAPHICS_IDENTITY_MAX = 20; struct remote_domain_event_graphics_identity { remote_nonnull_string type; remote_nonnull_string name; }; struct remote_domain_event_graphics_msg { remote_nonnull_domain dom; int phase; remote_domain_event_graphics_address local; remote_domain_event_graphics_address remote; remote_nonnull_string authScheme; remote_domain_event_graphics_identity subject<REMOTE_DOMAIN_EVENT_GRAPHICS_IDENTITY_MAX>; }; This is currently implemented in QEMU for the VNC graphics protocol, but designed to be usable with SPICE graphics in the future too. * daemon/remote.c: Dispatch graphics events to client * examples/domain-events/events-c/event-test.c: Watch for graphics events * include/libvirt/libvirt.h.in: Define new graphics event ID and callback signature * src/conf/domain_event.c, src/conf/domain_event.h, src/libvirt_private.syms: Extend API to handle graphics events * src/qemu/qemu_driver.c: Connect to the QEMU monitor event for VNC events and emit a libvirt graphics event * src/remote/remote_driver.c: Receive and dispatch graphics events to application * src/remote/remote_protocol.x: Wire protocol definition for graphics events * src/qemu/qemu_monitor.c, src/qemu/qemu_monitor.h, src/qemu/qemu_monitor_json.c: Watch for VNC_CONNECTED, VNC_INITIALIZED & VNC_DISCONNETED events from QEMU monitor
2010-03-19 13:27:45 +00:00
virDomainEventGraphicsNewFromDom;
virDomainEventGraphicsNewFromObj;
virDomainEventFree;
virDomainEventDispatchDefaultFunc;
virDomainEventDispatch;
virDomainEventQueueDispatch;
# ebtables.h
ebtablesAddForwardAllowIn;
ebtablesAddForwardPolicyReject;
ebtablesContextNew;
ebtablesRemoveForwardAllowIn;
# event.h
virEventAddHandle;
virEventAddTimeout;
virEventRemoveHandle;
virEventRemoveTimeout;
virEventUpdateHandle;
virEventUpdateTimeout;
# hash.h
virHashAddEntry;
virHashCreate;
virHashForEach;
virHashFree;
virHashLookup;
virHashRemoveEntry;
virHashRemoveSet;
virHashSearch;
virHashSize;
# hooks.h
virHookCall;
virHookInitialize;
virHookPresent;
# interface_conf.h
virInterfaceDefFormat;
virInterfaceDefParseFile;
virInterfaceDefParseString;
virInterfaceDefParseNode;
virInterfaceDefFree;
virInterfaceFindByName;
virInterfaceFindByMACString;
virInterfaceAssignDef;
virInterfaceRemove;
virInterfaceObjLock;
virInterfaceObjUnlock;
virInterfaceObjListFree;
# iptables.h
iptablesAddForwardAllowCross;
iptablesAddForwardAllowIn;
iptablesAddForwardAllowOut;
iptablesAddForwardAllowRelatedIn;
iptablesAddForwardMasquerade;
iptablesAddForwardRejectIn;
iptablesAddForwardRejectOut;
iptablesAddTcpInput;
iptablesAddUdpInput;
iptablesContextFree;
iptablesContextNew;
iptablesRemoveForwardAllowCross;
iptablesRemoveForwardAllowIn;
iptablesRemoveForwardAllowOut;
iptablesRemoveForwardAllowRelatedIn;
iptablesRemoveForwardMasquerade;
iptablesRemoveForwardRejectIn;
iptablesRemoveForwardRejectOut;
iptablesRemoveTcpInput;
iptablesRemoveUdpInput;
# libvirt_internal.h
virDrvSupportsFeature;
virDomainMigratePrepare;
virDomainMigratePerform;
virDomainMigrateFinish;
virDomainMigratePrepare2;
virDomainMigrateFinish2;
virDomainMigratePrepareTunnel;
virRegisterDriver;
virRegisterInterfaceDriver;
virRegisterNetworkDriver;
virRegisterStorageDriver;
virRegisterDeviceMonitor;
virRegisterSecretDriver;
virRegisterNWFilterDriver;
# json.h
virJSONValueFree;
virJSONValueNewString;
virJSONValueNewStringLen;
virJSONValueNewNumberInt;
virJSONValueNewNumberUint;
virJSONValueNewNumberLong;
virJSONValueNewNumberUlong;
virJSONValueNewNumberDouble;
virJSONValueNewBoolean;
virJSONValueNewNull;
virJSONValueNewArray;
virJSONValueNewObject;
virJSONValueObjectAppend;
virJSONValueObjectAppendString;
virJSONValueObjectAppendNumberInt;
virJSONValueObjectAppendNumberUint;
virJSONValueObjectAppendNumberLong;
virJSONValueObjectAppendNumberUlong;
virJSONValueObjectAppendNumberDouble;
virJSONValueObjectAppendBoolean;
virJSONValueObjectAppendNull;
virJSONValueArrayAppend;
virJSONValueObjectHasKey;
virJSONValueObjectGet;
virJSONValueArraySize;
virJSONValueArrayGet;
virJSONValueGetString;
virJSONValueGetNumberInt;
virJSONValueGetNumberUint;
virJSONValueGetNumberLong;
virJSONValueGetNumberUlong;
virJSONValueGetNumberDouble;
virJSONValueGetBoolean;
virJSONValueIsNull;
virJSONValueObjectGetString;
virJSONValueObjectGetNumberInt;
virJSONValueObjectGetNumberUint;
virJSONValueObjectGetNumberLong;
virJSONValueObjectGetNumberUlong;
virJSONValueObjectGetNumberDouble;
virJSONValueObjectGetBoolean;
virJSONValueObjectIsNull;
virJSONValueFromString;
virJSONValueToString;
# logging.h
virLogMessage;
virLogGetNbFilters;
virLogGetNbOutputs;
virLogGetFilters;
virLogGetOutputs;
virLogGetDefaultPriority;
virLogSetDefaultPriority;
virLogSetFromEnv;
virLogDefineFilter;
virLogDefineOutput;
virLogParseDefaultPriority;
virLogParseFilters;
virLogParseOutputs;
virLogStartup;
virLogShutdown;
virLogReset;
virLogLock;
virLogUnlock;
# memory.h
virAlloc;
virAllocN;
virReallocN;
virFree;
# network.h
virSocketAddrIsNetmask;
virSocketCheckNetmask;
virSocketFormatAddr;
virSocketGetPort;
virSocketGetRange;
virSocketParseAddr;
virSocketParseIpv4Addr;
virSocketParseIpv6Addr;
virSocketSetPort;
# network_conf.h
virNetworkAssignDef;
virNetworkConfigFile;
virNetworkDefFormat;
virNetworkDefFree;
virNetworkDefParseFile;
virNetworkDefParseNode;
virNetworkDefParseString;
virNetworkDeleteConfig;
virNetworkFindByName;
virNetworkFindByUUID;
virNetworkLoadAllConfigs;
virNetworkObjListFree;
virNetworkDefParseNode;
virNetworkRemoveInactive;
virNetworkSaveConfig;
virNetworkSetBridgeName;
virNetworkObjLock;
virNetworkObjUnlock;
# nodeinfo.h
2009-06-03 13:28:02 +00:00
nodeGetInfo;
nodeCapsInitNUMA;
nodeGetCellsFreeMemory;
nodeGetFreeMemory;
# node_device_conf.h
virNodeDeviceHasCap;
virNodeDeviceObjRemove;
virNodeDevCapTypeToString;
virNodeDeviceFindByName;
virNodeDeviceFindBySysfsPath;
virNodeDeviceObjListFree;
virNodeDeviceDefFree;
virNodeDevCapsDefFree;
virNodeDeviceDefFormat;
virNodeDeviceDefParseString;
virNodeDeviceObjLock;
virNodeDeviceObjUnlock;
virNodeDeviceAssignDef;
virNodeDeviceGetWWNs;
virNodeDeviceGetParentHost;
# nwfilter_conf.h
virNWFilterPoolLoadAllConfigs;
virNWFilterPoolObjAssignDef;
virNWFilterPoolObjSaveDef;
virNWFilterPoolObjFindByName;
virNWFilterPoolObjFindByUUID;
virNWFilterPoolObjLock;
virNWFilterPoolObjUnlock;
virNWFilterPoolObjRemove;
virNWFilterDefFree;
virNWFilterDefParseString;
virNWFilterPoolObjDeleteDef;
virNWFilterPoolObjListFree;
virNWFilterDefFormat;
virNWFilterChainSuffixTypeToString;
virNWFilterRuleActionTypeToString;
virNWFilterRuleProtocolTypeToString;
virNWFilterJumpTargetTypeToString;
virNWFilterRegisterCallbackDriver;
virNWFilterTestUnassignDef;
virNWFilterConfLayerInit;
virNWFilterConfLayerShutdown;
nwfilter: Support for learning a VM's IP address This patch implements support for learning a VM's IP address. It uses the pcap library to listen on the VM's backend network interface (tap) or the physical ethernet device (macvtap) and tries to capture packets with source or destination MAC address of the VM and learn from DHCP Offers, ARP traffic, or first-sent IPv4 packet what the IP address of the VM's interface is. This then allows to instantiate the network traffic filtering rules without the user having to provide the IP parameter somewhere in the filter description or in the interface description as a parameter. This only supports to detect the parameter IP, which is for the assumed single IPv4 address of a VM. There is not support for interfaces that may have multiple IP addresses (IP aliasing) or IPv6 that may then require more than one valid IP address to be detected. A VM can have multiple independent interfaces that each uses a different IP address and in that case it will be attempted to detect each one of the address independently. So, when for example an interface description in the domain XML has looked like this up to now: <interface type='bridge'> <source bridge='mybridge'/> <model type='virtio'/> <filterref filter='clean-traffic'> <parameter name='IP' value='10.2.3.4'/> </filterref> </interface> you may omit the IP parameter: <interface type='bridge'> <source bridge='mybridge'/> <model type='virtio'/> <filterref filter='clean-traffic'/> </interface> Internally I am walking the 'tree' of a VM's referenced network filters and determine with the given variables which variables are missing. Now, the above IP parameter may be missing and this causes a libvirt-internal thread to be started that uses the pcap library's API to listen to the backend interface (in case of macvtap to the physical interface) in an attempt to determine the missing IP parameter. If the backend interface disappears the thread terminates assuming the VM was brought down. In case of a macvtap device a timeout is being used to wait for packets from the given VM (filtering by VM's interface MAC address). If the VM's macvtap device disappeared the thread also terminates. In all other cases it tries to determine the IP address of the VM and will then apply the rules late on the given interface, which would have happened immediately if the IP parameter had been explicitly given. In case an error happens while the firewall rules are applied, the VM's backend interface is 'down'ed preventing it to communicate. Reasons for failure for applying the network firewall rules may that an ebtables/iptables command failes or OOM errors. Essentially the same failure reasons may occur as when the firewall rules are applied immediately on VM start, except that due to the late application of the filtering rules the VM now is already running and cannot be hindered anymore from starting. Bringing down the whole VM would probably be considered too drastic. While a VM's IP address is attempted to be determined only limited updates to network filters are allowed. In particular it is prevented that filters are modified in such a way that they would introduce new variables. A caveat: The algorithm does not know which one is the appropriate IP address of a VM. If the VM spoofs an IP address in its first ARP traffic or IPv4 packets its filtering rules will be instantiated for this IP address, thus 'locking' it to the found IP address. So, it's still 'safer' to explicitly provide the IP address of a VM's interface in the filter description if it is known beforehand. * configure.ac: detect libpcap * libvirt.spec.in: require libpcap[-devel] if qemu is built * src/internal.h: add the new ATTRIBUTE_PACKED define * src/Makefile.am src/libvirt_private.syms: add the new modules and symbols * src/nwfilter/nwfilter_learnipaddr.[ch]: new module being added * src/nwfilter/nwfilter_driver.c src/conf/nwfilter_conf.[ch] src/nwfilter/nwfilter_ebiptables_driver.[ch] src/nwfilter/nwfilter_gentech_driver.[ch]: plu the new functionality in * tests/nwfilterxml2xmltest: extend testing
2010-04-07 21:02:18 +00:00
virNWFilterLockFilterUpdates;
virNWFilterUnlockFilterUpdates;
#nwfilter_params.h
virNWFilterHashTableCreate;
virNWFilterHashTableFree;
virNWFilterHashTablePut;
virNWFilterHashTablePutAll;
virNWFilterHashTableRemoveEntry;
# nwfilter_gentech_driver.h
virNWFilterInstantiateFilter;
virNWFilterTeardownFilter;
# nwfilter_learnipaddr.h
nwfilter: Support for learning a VM's IP address This patch implements support for learning a VM's IP address. It uses the pcap library to listen on the VM's backend network interface (tap) or the physical ethernet device (macvtap) and tries to capture packets with source or destination MAC address of the VM and learn from DHCP Offers, ARP traffic, or first-sent IPv4 packet what the IP address of the VM's interface is. This then allows to instantiate the network traffic filtering rules without the user having to provide the IP parameter somewhere in the filter description or in the interface description as a parameter. This only supports to detect the parameter IP, which is for the assumed single IPv4 address of a VM. There is not support for interfaces that may have multiple IP addresses (IP aliasing) or IPv6 that may then require more than one valid IP address to be detected. A VM can have multiple independent interfaces that each uses a different IP address and in that case it will be attempted to detect each one of the address independently. So, when for example an interface description in the domain XML has looked like this up to now: <interface type='bridge'> <source bridge='mybridge'/> <model type='virtio'/> <filterref filter='clean-traffic'> <parameter name='IP' value='10.2.3.4'/> </filterref> </interface> you may omit the IP parameter: <interface type='bridge'> <source bridge='mybridge'/> <model type='virtio'/> <filterref filter='clean-traffic'/> </interface> Internally I am walking the 'tree' of a VM's referenced network filters and determine with the given variables which variables are missing. Now, the above IP parameter may be missing and this causes a libvirt-internal thread to be started that uses the pcap library's API to listen to the backend interface (in case of macvtap to the physical interface) in an attempt to determine the missing IP parameter. If the backend interface disappears the thread terminates assuming the VM was brought down. In case of a macvtap device a timeout is being used to wait for packets from the given VM (filtering by VM's interface MAC address). If the VM's macvtap device disappeared the thread also terminates. In all other cases it tries to determine the IP address of the VM and will then apply the rules late on the given interface, which would have happened immediately if the IP parameter had been explicitly given. In case an error happens while the firewall rules are applied, the VM's backend interface is 'down'ed preventing it to communicate. Reasons for failure for applying the network firewall rules may that an ebtables/iptables command failes or OOM errors. Essentially the same failure reasons may occur as when the firewall rules are applied immediately on VM start, except that due to the late application of the filtering rules the VM now is already running and cannot be hindered anymore from starting. Bringing down the whole VM would probably be considered too drastic. While a VM's IP address is attempted to be determined only limited updates to network filters are allowed. In particular it is prevented that filters are modified in such a way that they would introduce new variables. A caveat: The algorithm does not know which one is the appropriate IP address of a VM. If the VM spoofs an IP address in its first ARP traffic or IPv4 packets its filtering rules will be instantiated for this IP address, thus 'locking' it to the found IP address. So, it's still 'safer' to explicitly provide the IP address of a VM's interface in the filter description if it is known beforehand. * configure.ac: detect libpcap * libvirt.spec.in: require libpcap[-devel] if qemu is built * src/internal.h: add the new ATTRIBUTE_PACKED define * src/Makefile.am src/libvirt_private.syms: add the new modules and symbols * src/nwfilter/nwfilter_learnipaddr.[ch]: new module being added * src/nwfilter/nwfilter_driver.c src/conf/nwfilter_conf.[ch] src/nwfilter/nwfilter_ebiptables_driver.[ch] src/nwfilter/nwfilter_gentech_driver.[ch]: plu the new functionality in * tests/nwfilterxml2xmltest: extend testing
2010-04-07 21:02:18 +00:00
virNWFilterGetIpAddrForIfname;
virNWFilterDelIpAddrForIfname;
virNWFilterLookupLearnReq;
# pci.h
pciGetDevice;
pciFreeDevice;
pciDettachDevice;
pciReAttachDevice;
pciWaitForDeviceCleanup;
pciResetDevice;
pciDeviceSetManaged;
pciDeviceGetManaged;
pciDeviceListNew;
pciDeviceListFree;
pciDeviceListAdd;
pciDeviceListDel;
pciDeviceFileIterate;
pciDeviceListCount;
pciDeviceListGet;
pciDeviceListSteal;
pciDeviceIsAssignable;
# processinfo.h
virProcessInfoSetAffinity;
virProcessInfoGetAffinity;
# qparams.h
qparam_get_query;
qparam_query_parse;
free_qparam_set;
# secret_conf.h
virSecretDefFree;
virSecretDefParseString;
virSecretDefParseFile;
virSecretDefFormat;
# security.h
virSecurityDriverVerify;
virSecurityDriverStartup;
virSecurityDriverInit;
virSecurityDriverSetDOI;
virSecurityDriverGetDOI;
virSecurityDriverGetModel;
# storage_conf.h
virStoragePoolDefFormat;
virStoragePoolDefFree;
virStoragePoolDefParseString;
virStoragePoolDefParseFile;
virStoragePoolDefParseNode;
virStoragePoolLoadAllConfigs;
virStoragePoolObjAssignDef;
virStoragePoolObjClearVols;
virStoragePoolObjDeleteDef;
virStoragePoolObjFindByName;
virStoragePoolObjFindByUUID;
virStoragePoolObjListFree;
virStoragePoolObjRemove;
virStoragePoolObjSaveDef;
virStoragePoolSourceFree;
virStoragePoolDefParseSourceString;
virStoragePoolSourceListNewSource;
virStoragePoolSourceListFormat;
virStorageVolDefFindByKey;
virStorageVolDefFindByName;
virStorageVolDefFindByPath;
virStorageVolDefFormat;
virStorageVolDefFree;
virStorageVolDefParseFile;
virStorageVolDefParseString;
virStorageVolDefParseNode;
virStoragePoolFormatDiskTypeToString;
virStoragePoolFormatFileSystemTypeToString;
virStoragePoolFormatFileSystemNetTypeToString;
virStoragePoolTypeFromString;
virStoragePartedFsTypeTypeToString;
virStoragePoolObjLock;
virStoragePoolObjUnlock;
# storage_encryption_conf.h
virStorageEncryptionFree;
virStorageEncryptionParseNode;
virStorageEncryptionFormat;
virStorageGenerateQcowPassphrase;
# storage_file.h
virStorageFileFormatTypeToString;
virStorageFileFormatTypeFromString;
virStorageFileGetMetadata;
virStorageFileGetMetadataFromFD;
2009-01-15 19:56:05 +00:00
# threads.h
virMutexInit;
virMutexDestroy;
virMutexLock;
virMutexUnlock;
virCondInit;
virCondDestroy;
virCondWait;
virCondWaitUntil;
2009-01-15 19:56:05 +00:00
virCondSignal;
virCondBroadcast;
# util.h
virFileReadAll;
virFileWriteStr;
virStrToLong_i;
virStrToLong_ll;
virStrToLong_ull;
virStrToLong_ui;
virStrToDouble;
virFileLinkPointsTo;
2009-04-01 10:26:22 +00:00
virFileResolveLink;
saferead;
safewrite;
safezero;
virMacAddrCompare;
virEnumFromString;
virEnumToString;
virEventAddHandle;
virEventRemoveHandle;
virExec;
virExecDaemonize;
virSetCloseExec;
2009-01-20 16:36:34 +00:00
virSetNonBlock;
virFormatMacAddr;
virGetHostnameLocalhost;
virGetHostname;
virParseMacAddr;
virFileDeletePid;
virFindFileInPath;
virFileExists;
virFileHasSuffix;
virFileLinkPointsTo;
virFileMakePath;
virFileAbsPath;
virFileOpenTty;
virFileReadLimFD;
virFilePid;
virFileReadPid;
virFileLinkPointsTo;
virParseNumber;
virParseVersionString;
virPipeReadUntilEOF;
virAsprintf;
virRun;
virSkipSpaces;
2009-01-06 17:46:46 +00:00
virKillProcess;
2009-01-22 19:41:48 +00:00
virGetUserDirectory;
virGetUserName;
virGetUserID;
virGetGroupID;
virFileFindMountPoint;
virFileWaitForDevices;
virFileMatchesNameSuffix;
virArgvToString;
# usb.h
usbGetDevice;
usbFindDevice;
usbFreeDevice;
usbDeviceGetBus;
usbDeviceGetDevno;
usbDeviceFileIterate;
# uuid.h
virUUIDFormat;
virUUIDGenerate;
virUUIDParse;
# virterror_internal.h
virReportErrorHelper;
virErrorMsg;
virRaiseErrorFull;
virReportSystemErrorFull;
virReportOOMErrorFull;
virStrerror;
virSetError;
# xml.h
virXPathBoolean;
virXPathLong;
virXPathNode;
virXPathNodeSet;
virXPathString;
virXMLPropString;
virXPathStringLimit;
virXPathBoolean;
virXPathNumber;
virXPathULong;
virXPathLongLong;
virXPathULongLong;
virXPathLongHex;
virXPathULongHex;