libvirt/po/POTFILES.in

205 lines
4.9 KiB
Plaintext
Raw Normal View History

daemon/libvirtd-config.c
2009-09-16 16:26:27 +00:00
daemon/libvirtd.c
daemon/qemu_dispatch.h
2009-09-16 16:26:27 +00:00
daemon/remote.c
daemon/remote_dispatch.h
daemon/stream.c
gnulib/lib/gai_strerror.c
gnulib/lib/regcomp.c
src/conf/cpu_conf.c
src/conf/device_conf.c
2009-09-16 16:26:27 +00:00
src/conf/domain_conf.c
2010-01-13 18:11:33 +00:00
src/conf/domain_event.c
2009-09-16 16:26:27 +00:00
src/conf/interface_conf.c
src/conf/netdev_bandwidth_conf.c
conf: add <vlan> element to network and domain interface elements The following config elements now support a <vlan> subelements: within a domain: <interface>, and the <actual> subelement of <interface> within a network: the toplevel, as well as any <portgroup> Each vlan element must have one or more <tag id='n'/> subelements. If there is more than one tag, it is assumed that vlan trunking is being requested. If trunking is required with only a single tag, the attribute "trunk='yes'" should be added to the toplevel <vlan> element. Some examples: <interface type='hostdev'/> <vlan> <tag id='42'/> </vlan> <mac address='52:54:00:12:34:56'/> ... </interface> <network> <name>vlan-net</name> <vlan trunk='yes'> <tag id='30'/> </vlan> <virtualport type='openvswitch'/> </network> <interface type='network'/> <source network='vlan-net'/> ... </interface> <network> <name>trunk-vlan</name> <vlan> <tag id='42'/> <tag id='43'/> </vlan> ... </network> <network> <name>multi</name> ... <portgroup name='production'/> <vlan> <tag id='42'/> </vlan> </portgroup> <portgroup name='test'/> <vlan> <tag id='666'/> </vlan> </portgroup> </network> <interface type='network'/> <source network='multi' portgroup='test'/> ... </interface> IMPORTANT NOTE: As of this patch there is no backend support for the vlan element for *any* network device type. When support is added in later patches, it will only be for those select network types that support setting up a vlan on the host side, without the guest's involvement. (For example, it will be possible to configure a vlan for a guest connected to an openvswitch bridge, but it won't be possible to do that for one that is connected to a standard Linux host bridge.)
2012-08-12 07:51:30 +00:00
src/conf/netdev_vlan_conf.c
src/conf/netdev_vport_profile_conf.c
2009-09-16 16:26:27 +00:00
src/conf/network_conf.c
src/conf/node_device_conf.c
src/conf/nwfilter_conf.c
src/conf/nwfilter_params.c
2009-09-16 16:26:27 +00:00
src/conf/secret_conf.c
src/conf/snapshot_conf.c
2009-09-16 16:26:27 +00:00
src/conf/storage_conf.c
src/conf/storage_encryption_conf.c
src/conf/virconsole.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 15:02:11 +00: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 15:02:11 +00:00
src/cpu/cpu_map.c
src/cpu/cpu_x86.c
src/datatypes.c
src/driver.c
src/esx/esx_driver.c
esx: Implement network driver An ESX server has one or more PhysicalNics that represent the actual hardware NICs. Those can be listed via the interface driver. A libvirt virtual network is mapped to a HostVirtualSwitch. On the physical side a HostVirtualSwitch can be connected to PhysicalNics. On the virtual side a HostVirtualSwitch has HostPortGroups that are mapped to libvirt virtual network's portgroups. Typically there is HostPortGroups named 'VM Network' that is used to connect virtual machines to a HostVirtualSwitch. A second HostPortGroup typically named 'Management Network' is used to connect the hypervisor itself to the HostVirtualSwitch. This one is not mapped to a libvirt virtual network's portgroup. There can be more HostPortGroups than those typical two on a HostVirtualSwitch. +---------------+-------------------+ ...---| | | +-------------+ | HostPortGroup | |---| PhysicalNic | | VM Network | | | vmnic0 | ...---| | | +-------------+ +---------------+ HostVirtualSwitch | | vSwitch0 | +---------------+ | | HostPortGroup | | ...---| Management | | | Network | | +---------------+-------------------+ The virtual counterparts of the PhysicalNic is the HostVirtualNic for the hypervisor and the VirtualEthernetCard for the virtual machines that are grouped into HostPortGroups. +---------------------+ +---------------+---... | VirtualEthernetCard |---| | +---------------------+ | HostPortGroup | +---------------------+ | VM Network | | VirtualEthernetCard |---| | +---------------------+ +---------------+ | +---------------+ +---------------------+ | HostPortGroup | | HostVirtualNic |---| Management | +---------------------+ | Network | +---------------+---... The currently implemented network driver can list, define and undefine HostVirtualSwitches including HostPortGroups for virtual machines. Existing HostVirtualSwitches cannot be edited yet. This will be added in a followup patch.
2012-08-05 20:11:50 +00:00
src/esx/esx_network_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/fdstream.c
2011-07-13 14:47:01 +00:00
src/hyperv/hyperv_driver.c
src/hyperv/hyperv_util.c
src/hyperv/hyperv_wmi.c
2009-09-16 16:26:27 +00:00
src/interface/netcf_driver.c
2010-04-16 17:21:10 +00:00
src/internal.h
src/libvirt.c
src/libvirt-qemu.c
src/locking/lock_driver_sanlock.c
src/locking/lock_manager.c
src/lxc/lxc_cgroup.c
2009-09-16 16:26:27 +00:00
src/lxc/lxc_container.c
src/lxc/lxc_conf.c
2009-09-16 16:26:27 +00:00
src/lxc/lxc_controller.c
src/lxc/lxc_driver.c
src/lxc/lxc_monitor.c
src/lxc/lxc_process.c
src/libxl/libxl_driver.c
src/libxl/libxl_conf.c
2009-09-16 16:26:27 +00: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_dhcpsnoop.c
src/nwfilter/nwfilter_driver.c
src/nwfilter/nwfilter_ebiptables_driver.c
src/nwfilter/nwfilter_gentech_driver.c
src/nwfilter/nwfilter_learnipaddr.c
2009-09-16 16:26:27 +00:00
src/openvz/openvz_conf.c
src/openvz/openvz_driver.c
2012-05-15 15:27:08 +00:00
src/openvz/openvz_util.c
src/parallels/parallels_driver.c
src/parallels/parallels_utils.c
src/parallels/parallels_storage.c
src/phyp/phyp_driver.c
src/qemu/qemu_agent.c
src/qemu/qemu_bridge_filter.c
src/qemu/qemu_capabilities.c
src/qemu/qemu_cgroup.c
src/qemu/qemu_command.c
2009-09-16 16:26:27 +00:00
src/qemu/qemu_conf.c
src/qemu/qemu_domain.c
2009-09-16 16:26:27 +00:00
src/qemu/qemu_driver.c
src/qemu/qemu_hostdev.c
src/qemu/qemu_hotplug.c
src/qemu/qemu_migration.c
src/qemu/qemu_monitor.c
src/qemu/qemu_monitor_json.c
src/qemu/qemu_monitor_text.c
src/qemu/qemu_process.c
src/remote/remote_client_bodies.h
2009-09-16 16:26:27 +00:00
src/remote/remote_driver.c
src/rpc/virkeepalive.c
src/rpc/virnetclient.c
src/rpc/virnetclientprogram.c
src/rpc/virnetclientstream.c
src/rpc/virnetmessage.c
src/rpc/virnetsaslcontext.c
src/rpc/virnetsocket.c
src/rpc/virnetserver.c
src/rpc/virnetserverclient.c
src/rpc/virnetservermdns.c
src/rpc/virnetserverprogram.c
src/rpc/virnetsshsession.c
src/rpc/virnettlscontext.c
2009-09-16 16:26:27 +00:00
src/secret/secret_driver.c
src/security/security_apparmor.c
Refactor the security drivers to simplify usage The current security driver usage requires horrible code like if (driver->securityDriver && driver->securityDriver->domainSetSecurityHostdevLabel && driver->securityDriver->domainSetSecurityHostdevLabel(driver->securityDriver, vm, hostdev) < 0) This pair of checks for NULL clutters up the code, making the driver calls 2 lines longer than they really need to be. The goal of the patchset is to change the calling convention to simply if (virSecurityManagerSetHostdevLabel(driver->securityDriver, vm, hostdev) < 0) The first check for 'driver->securityDriver' being NULL is removed by introducing a 'no op' security driver that will always be present if no real driver is enabled. This guarentees driver->securityDriver != NULL. The second check for 'driver->securityDriver->domainSetSecurityHostdevLabel' being non-NULL is hidden in a new abstraction called virSecurityManager. This separates the driver callbacks, from main internal API. The addition of a virSecurityManager object, that is separate from the virSecurityDriver struct also allows for security drivers to carry state / configuration information directly. Thus the DAC/Stack drivers from src/qemu which used to pull config from 'struct qemud_driver' can now be moved into the 'src/security' directory and store their config directly. * src/qemu/qemu_conf.h, src/qemu/qemu_driver.c: Update to use new virSecurityManager APIs * src/qemu/qemu_security_dac.c, src/qemu/qemu_security_dac.h src/qemu/qemu_security_stacked.c, src/qemu/qemu_security_stacked.h: Move into src/security directory * src/security/security_stack.c, src/security/security_stack.h, src/security/security_dac.c, src/security/security_dac.h: Generic versions of previous QEMU specific drivers * src/security/security_apparmor.c, src/security/security_apparmor.h, src/security/security_driver.c, src/security/security_driver.h, src/security/security_selinux.c, src/security/security_selinux.h: Update to take virSecurityManagerPtr object as the first param in all callbacks * src/security/security_nop.c, src/security/security_nop.h: Stub implementation of all security driver APIs. * src/security/security_manager.h, src/security/security_manager.c: New internal API for invoking security drivers * src/libvirt.c: Add missing debug for security APIs
2010-11-17 20:26:30 +00:00
src/security/security_dac.c
src/security/security_driver.c
src/security/security_manager.c
2009-09-16 16:26:27 +00:00
src/security/security_selinux.c
src/security/virt-aa-helper.c
src/storage/parthelper.c
2009-09-16 16:26:27 +00: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_rbd.c
2009-09-16 16:26:27 +00:00
src/storage/storage_backend_scsi.c
src/storage/storage_backend_sheepdog.c
2009-09-16 16:26:27 +00:00
src/storage/storage_driver.c
src/test/test_driver.c
src/uml/uml_conf.c
src/uml/uml_driver.c
src/util/cgroup.c
src/util/command.c
2009-09-16 16:26:27 +00:00
src/util/conf.c
src/util/dnsmasq.c
src/util/event_poll.c
src/util/hooks.c
src/util/hostusb.c
src/util/iohelper.c
src/util/iptables.c
src/util/json.c
2009-09-16 16:26:27 +00:00
src/util/pci.c
src/util/processinfo.c
src/util/sexpr.c
src/util/stats_linux.c
src/util/storage_file.c
src/util/sysinfo.c
2009-09-16 16:26:27 +00:00
src/util/util.c
src/util/viraudit.c
src/util/virauth.c
src/util/virauthconfig.c
src/util/virdbus.c
src/util/virfile.c
src/util/virhash.c
src/util/virkeyfile.c
src/util/virnetdev.c
src/util/virnetdevbridge.c
src/util/virnetdevmacvlan.c
src/util/virnetdevopenvswitch.c
src/util/virnetdevtap.c
src/util/virnetdevvportprofile.c
src/util/virnetlink.c
src/util/virnodesuspend.c
src/util/virpidfile.c
src/util/virrandom.c
src/util/virsocketaddr.c
2009-09-16 16:26:27 +00:00
src/util/virterror.c
src/util/virterror_internal.h
src/util/virtime.c
src/util/virtypedparam.c
src/util/viruri.c
2009-09-16 16:26:27 +00:00
src/util/xml.c
src/vbox/vbox_MSCOMGlue.c
src/vbox/vbox_XPCOMCGlue.c
src/vbox/vbox_driver.c
src/vbox/vbox_tmpl.c
src/vmware/vmware_conf.c
src/vmware/vmware_driver.c
src/vmx/vmx.c
src/xen/block_stats.c
2009-09-16 16:26:27 +00:00
src/xen/xen_driver.c
src/xen/xen_hypervisor.c
src/xen/xen_inotify.c
src/xen/xend_internal.c
2009-09-16 16:26:27 +00:00
src/xen/xm_internal.c
src/xen/xs_internal.c
src/xenapi/xenapi_driver.c
src/xenapi/xenapi_utils.c
2011-02-21 13:40:08 +00:00
src/xenxs/xen_sxpr.c
2011-02-21 13:40:10 +00:00
src/xenxs/xen_xm.c
2009-09-16 16:26:27 +00:00
tools/console.c
tools/libvirt-guests.init.sh
2009-09-16 16:26:27 +00:00
tools/virsh.c
tools/virsh-domain-monitor.c
tools/virsh-domain.c
tools/virsh-edit.c
tools/virsh-host.c
tools/virsh-interface.c
tools/virsh-network.c
tools/virsh-nodedev.c
tools/virsh-nwfilter.c
tools/virsh-pool.c
tools/virsh-secret.c
tools/virsh-snapshot.c
tools/virsh-volume.c
tools/virt-host-validate-common.c
tools/virt-host-validate-lxc.c
tools/virt-host-validate-qemu.c
tools/virt-host-validate.c