libvirt/src/qemu/qemu_command.h

205 lines
7.7 KiB
C
Raw Normal View History

/*
* qemu_command.h: QEMU command generation
*
* Copyright (C) 2006-2016 Red Hat, Inc.
* Copyright (C) 2006 Daniel P. Berrange
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2.1 of the License, or (at your option) any later version.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
* License along with this library. If not, see
* <http://www.gnu.org/licenses/>.
*
* Author: Daniel P. Berrange <berrange@redhat.com>
*/
#ifndef __QEMU_COMMAND_H__
# define __QEMU_COMMAND_H__
# include "domain_addr.h"
# include "domain_conf.h"
# include "vircommand.h"
# include "capabilities.h"
# include "qemu_conf.h"
# include "qemu_domain.h"
# include "qemu_domain_address.h"
# include "qemu_capabilities.h"
# include "logging/log_manager.h"
/* Config type for XML import/export conversions */
# define QEMU_CONFIG_FORMAT_ARGV "qemu-argv"
# define QEMU_FSDEV_HOST_PREFIX "fsdev-"
# define QEMU_BLOCK_IOTUNE_MAX 1000000000000000LL
VIR_ENUM_DECL(qemuVideo)
virCommandPtr qemuBuildCommandLine(virQEMUDriverPtr driver,
virLogManagerPtr logManager,
virDomainDefPtr def,
virDomainChrSourceDefPtr monitor_chr,
bool monitor_json,
virQEMUCapsPtr qemuCaps,
const char *migrateURI,
virDomainSnapshotObjPtr snapshot,
virNetDevVPortProfileOp vmop,
bool standalone,
bool enableFips,
virBitmapPtr nodeset,
size_t *nnicindexes,
int **nicindexes,
const char *domainLibDir)
ATTRIBUTE_NONNULL(15);
/* Generate the object properties for a secret */
int qemuBuildSecretInfoProps(qemuDomainSecretInfoPtr secinfo,
virJSONValuePtr *propsret);
/* Generate the object properties for a tls-creds-x509 */
int qemuBuildTLSx509BackendProps(const char *tlspath,
bool isListen,
bool verifypeer,
const char *secalias,
virQEMUCapsPtr qemuCaps,
virJSONValuePtr *propsret);
/* Generate '-device' string for chardev device */
int
qemuBuildChrDeviceStr(char **deviceStr,
const virDomainDef *vmdef,
virDomainChrDefPtr chr,
virQEMUCapsPtr qemuCaps);
/* With vlan == -1, use netdev syntax, else old hostnet */
char *qemuBuildHostNetStr(virDomainNetDefPtr net,
virQEMUDriverPtr driver,
char type_sep,
int vlan,
char **tapfd,
size_t tapfdSize,
char **vhostfd,
size_t vhostfdSize);
/* Legacy, pre device support */
char *qemuBuildNicStr(virDomainNetDefPtr net,
const char *prefix,
int vlan);
/* Current, best practice */
char *qemuBuildNicDevStr(virDomainDefPtr def,
virDomainNetDefPtr net,
int vlan,
unsigned int bootindex,
size_t vhostfdSize,
qemu: propagate bridge MTU into qemu "host_mtu" option libvirt was able to set the host_mtu option when an MTU was explicitly given in the interface config (with <mtu size='n'/>), set the MTU of a libvirt network in the network config (with the same named subelement), and would automatically set the MTU of any tap device to the MTU of the network. This patch ties that all together (for networks based on tap devices and either Linux host bridges or OVS bridges) by learning the MTU of the network (i.e. the bridge) during qemuInterfaceBridgeConnect(), and returning that value so that it can then be passed to qemuBuildNicDevStr(); qemuBuildNicDevStr() then sets host_mtu in the interface's commandline options. The result is that a higher MTU for all guests connecting to a particular network will be plumbed top to bottom by simply changing the MTU of the network (in libvirt's config for libvirt-managed networks, or directly on the bridge device for simple host bridges or OVS bridges managed outside of libvirt). One question I have about this - it occurred to me that in the case of migrating a guest from a host with an older libvirt to one with a newer libvirt, the guest may have *not* had the host_mtu option on the older machine, but *will* have it on the newer machine. I'm curious if this could lead to incompatibilities between source and destination (I guess it all depends on whether or not the setting of host_mtu has a practical effect on a guest that is already running - Maxime?) Likewise, we could run into problems when migrating from a newer libvirt to older libvirt - The guest would have been told of the higher MTU on the newer libvirt, then migrated to a host that didn't understand <mtu size='blah'/>. (If this really is a problem, it would be a problem with or without the current patch).
2017-02-03 16:55:20 +00:00
virQEMUCapsPtr qemuCaps,
unsigned int mtu);
char *qemuDeviceDriveHostAlias(virDomainDiskDefPtr disk);
/* Both legacy & current support */
char *qemuBuildDriveStr(virDomainDiskDefPtr disk,
virQEMUDriverConfigPtr cfg,
bool bootable,
virQEMUCapsPtr qemuCaps);
/* Current, best practice */
char *qemuBuildDriveDevStr(const virDomainDef *def,
virDomainDiskDefPtr disk,
unsigned int bootindex,
virQEMUCapsPtr qemuCaps);
/* Current, best practice */
char *qemuBuildControllerDevStr(const virDomainDef *domainDef,
virDomainControllerDefPtr def,
virQEMUCapsPtr qemuCaps,
int *nusbcontroller);
int qemuBuildMemoryBackendStr(virJSONValuePtr *backendProps,
const char **backendType,
virQEMUDriverConfigPtr cfg,
virQEMUCapsPtr qemuCaps,
virDomainDefPtr def,
virDomainMemoryDefPtr mem,
virBitmapPtr autoNodeset,
bool force);
char *qemuBuildMemoryDeviceStr(virDomainMemoryDefPtr mem);
/* Current, best practice */
char *qemuBuildPCIHostdevDevStr(const virDomainDef *def,
virDomainHostdevDefPtr dev,
unsigned int bootIndex,
const char *configfd,
virQEMUCapsPtr qemuCaps);
char *qemuBuildRNGDevStr(const virDomainDef *def,
virDomainRNGDefPtr dev,
virQEMUCapsPtr qemuCaps);
int qemuBuildRNGBackendProps(virDomainRNGDefPtr rng,
virQEMUCapsPtr qemuCaps,
const char **type,
virJSONValuePtr *props);
int qemuOpenPCIConfig(virDomainHostdevDefPtr dev);
/* Current, best practice */
char *qemuBuildUSBHostdevDevStr(const virDomainDef *def,
virDomainHostdevDefPtr dev,
virQEMUCapsPtr qemuCaps);
char *qemuBuildSCSIHostdevDrvStr(virDomainHostdevDefPtr dev);
char *qemuBuildSCSIHostdevDevStr(const virDomainDef *def,
virDomainHostdevDefPtr dev,
virQEMUCapsPtr qemuCaps);
char *
qemuBuildSCSIVHostHostdevDevStr(const virDomainDef *def,
virDomainHostdevDefPtr dev,
virQEMUCapsPtr qemuCaps,
char *vhostfdName);
char *qemuBuildRedirdevDevStr(const virDomainDef *def,
virDomainRedirdevDefPtr dev,
virQEMUCapsPtr qemuCaps);
qemu: allocate network connections sooner during domain startup VFIO device assignment requires a cgroup ACL to be setup for access to the /dev/vfio/nn "group" device for any devices that will be assigned to a guest. In the case of a host device that is allocated from a pool, it was being allocated during qemuBuildCommandLine(), which is called by qemuProcessStart() *after* the all-encompassing qemuSetupCgroup() was called, meaning that the standard Cgroup ACL setup wasn't creating ACLs for these devices allocated from pools. One possible solution was to manually add a single ACL down inside qemuBuildCommandLine() when networkAllocateActualDevice() is called, but that has two problems: 1) the function that adds the cgroup ACL requires a virDomainObjPtr, which isn't available in qemuBuildCommandLine(), and 2) we really shouldn't be doing network device setup inside qemuBuildCommandLine() anyway. Instead, I've created a new function called qemuNetworkPrepareDevices() which is called just before qemuPrepareHostDevices() during qemuProcessStart() (explanation of ordering in the comments), i.e. well before the call to qemuSetupCgroup(). To minimize code churn in a patch that will be backported to 1.0.5-maint, qemuNetworkPrepareDevices only does networkAllocateActualDevice() and the bare amount of setup required for type='hostdev network devices, but it eventually should do *all* device setup for guest network devices. Note that some of the code that was previously needed in qemuBuildCommandLine() is no longer required when networkAllocateActualDevice() is called earlier: * qemuAssignDeviceHostdevAlias() is already done further down in qemuProcessStart(). * qemuPrepareHostdevPCIDevices() is called by qemuPrepareHostDevices() which is called after qemuNetworkPrepareDevices() in qemuProcessStart(). As hinted above, this new function should be moved into a separate qemu_network.c (or similarly named) file along with qemuPhysIfaceConnect(), qemuNetworkIfaceConnect(), and qemuOpenVhostNet(), and expanded to call those functions as well, then the nnets loop in qemuBuildCommandLine() should be reduced to only build the commandline string (which itself can be in a separate qemuInterfaceBuilldCommandLine() function as suggested by Michal). However, this will require storing away an array of tapfd and vhostfd that are needed for the commandline, so I would rather do that in a separate patch and leave this patch at the minimum to fix the bug.
2013-05-06 19:43:56 +00:00
int qemuNetworkPrepareDevices(virDomainDefPtr def);
int qemuGetDriveSourceString(virStorageSourcePtr src,
qemuDomainSecretInfoPtr secinfo,
char **source);
int qemuCheckDiskConfig(virDomainDiskDefPtr disk);
bool
qemuCheckFips(void);
bool qemuCheckCCWS390AddressSupport(const virDomainDef *def,
virDomainDeviceInfo info,
virQEMUCapsPtr qemuCaps,
const char *devicename);
virJSONValuePtr qemuBuildHotpluggableCPUProps(const virDomainVcpuDef *vcpu)
ATTRIBUTE_NONNULL(1);
virJSONValuePtr qemuBuildShmemBackendMemProps(virDomainShmemDefPtr shmem)
ATTRIBUTE_NONNULL(1);
char *qemuBuildShmemDevStr(virDomainDefPtr def,
virDomainShmemDefPtr shmem,
virQEMUCapsPtr qemuCaps)
ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(2) ATTRIBUTE_NONNULL(3);
#endif /* __QEMU_COMMAND_H__*/