1
0
mirror of https://gitlab.com/libvirt/libvirt.git synced 2024-12-25 01:34:11 +03:00
libvirt/po/POTFILES.in

109 lines
2.5 KiB
Plaintext
Raw Normal View History

2009-09-16 20:26:27 +04:00
daemon/dispatch.c
daemon/libvirtd.c
daemon/remote.c
daemon/stream.c
src/conf/cpu_conf.c
2009-09-16 20:26:27 +04:00
src/conf/domain_conf.c
2010-01-13 21:11:33 +03:00
src/conf/domain_event.c
2009-09-16 20:26:27 +04:00
src/conf/interface_conf.c
src/conf/network_conf.c
src/conf/node_device_conf.c
src/conf/nwfilter_conf.c
src/conf/nwfilter_params.c
2009-09-16 20:26:27 +04:00
src/conf/secret_conf.c
src/conf/storage_conf.c
src/conf/storage_encryption_conf.c
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 18:02:11 +03:00
src/cpu/cpu.c
src/cpu/cpu_generic.c
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 18:02:11 +03:00
src/cpu/cpu_map.c
src/cpu/cpu_x86.c
src/datatypes.c
src/driver.c
src/esx/esx_driver.c
src/esx/esx_storage_driver.c
src/esx/esx_util.c
src/esx/esx_vi.c
src/esx/esx_vi_methods.c
src/esx/esx_vi_types.c
src/esx/esx_vmx.c
2009-09-16 20:26:27 +04:00
src/interface/netcf_driver.c
2010-04-16 21:21:10 +04:00
src/internal.h
src/libvirt.c
2009-09-16 20:26:27 +04:00
src/lxc/lxc_container.c
src/lxc/lxc_conf.c
2009-09-16 20:26:27 +04:00
src/lxc/lxc_controller.c
src/lxc/lxc_driver.c
src/lxc/veth.c
2009-09-16 20:26:27 +04:00
src/network/bridge_driver.c
src/node_device/node_device_driver.c
src/node_device/node_device_hal.c
src/node_device/node_device_linux_sysfs.c
src/node_device/node_device_udev.c
src/nodeinfo.c
src/nwfilter/nwfilter_driver.c
src/nwfilter/nwfilter_ebiptables_driver.c
src/nwfilter/nwfilter_gentech_driver.c
src/nwfilter/nwfilter_learnipaddr.c
src/opennebula/one_conf.c
src/opennebula/one_driver.c
2009-09-16 20:26:27 +04:00
src/openvz/openvz_conf.c
src/openvz/openvz_driver.c
src/phyp/phyp_driver.c
src/qemu/qemu_bridge_filter.c
2009-09-16 20:26:27 +04:00
src/qemu/qemu_conf.c
src/qemu/qemu_driver.c
src/qemu/qemu_monitor.c
src/qemu/qemu_monitor_json.c
src/qemu/qemu_monitor_text.c
src/qemu/qemu_security_dac.c
2009-09-16 20:26:27 +04:00
src/remote/remote_driver.c
src/secret/secret_driver.c
src/security/security_apparmor.c
src/security/security_driver.c
2009-09-16 20:26:27 +04:00
src/security/security_selinux.c
src/security/virt-aa-helper.c
2009-09-16 20:26:27 +04:00
src/storage/storage_backend.c
src/storage/storage_backend_disk.c
src/storage/storage_backend_fs.c
src/storage/storage_backend_iscsi.c
src/storage/storage_backend_logical.c
src/storage/storage_backend_mpath.c
src/storage/storage_backend_scsi.c
src/storage/storage_driver.c
src/test/test_driver.c
src/uml/uml_conf.c
src/uml/uml_driver.c
src/util/authhelper.c
2009-09-16 20:26:27 +04:00
src/util/bridge.c
src/util/cgroup.c
2009-09-16 20:26:27 +04:00
src/util/conf.c
src/util/dnsmasq.c
src/util/hooks.c
src/util/hostusb.c
src/util/interface.c
src/util/iptables.c
src/util/json.c
src/util/macvtap.c
src/util/network.c
2009-09-16 20:26:27 +04:00
src/util/pci.c
src/util/processinfo.c
src/util/stats_linux.c
src/util/storage_file.c
2009-09-16 20:26:27 +04:00
src/util/util.c
src/util/virtaudit.c
2009-09-16 20:26:27 +04:00
src/util/virterror.c
src/util/xml.c
src/vbox/vbox_driver.c
src/vbox/vbox_tmpl.c
2009-09-16 20:26:27 +04:00
src/xen/proxy_internal.c
src/xen/xen_driver.c
src/xen/xen_hypervisor.c
src/xen/xen_inotify.c
src/xen/xend_internal.c
2009-09-16 20:26:27 +04:00
src/xen/xm_internal.c
src/xen/xs_internal.c
src/xenapi/xenapi_driver.c
src/xenapi/xenapi_utils.c
2009-09-16 20:26:27 +04:00
tools/console.c
tools/virsh.c