[libvirt] [PATCH 0/2] qemuDomainDiskChangeSupported: Add missing 'address' check
by Marc Hartmayer
Disk->info is not live updatable so add a check for this. Otherwise
libvirt reports success even though no data was updated.
Marc Hartmayer (2):
conf: Make virDomainDeviceInfoAddressIsEqual() public
qemu: qemuDomainDiskChangeSupported: Add missing 'address' check
src/conf/domain_conf.c | 3 +--
src/conf/domain_conf.h | 5 +++++
src/libvirt_private.syms | 1 +
src/qemu/qemu_domain.c | 13 +++++++++++++
4 files changed, 20 insertions(+), 2 deletions(-)
--
2.5.5
7 years, 11 months
Re: [libvirt] [Qemu-devel] [PATCH for-2.9 15/17] target-i386: Define static "base" CPU model
by Eduardo Habkost
On Mon, Dec 05, 2016 at 07:18:47PM +0100, David Hildenbrand wrote:
> Am 02.12.2016 um 22:18 schrieb Eduardo Habkost:
> > The query-cpu-model-expand QMP command needs at least one static
> > model, to allow the "static" expansion mode to be implemented.
> > Instead of defining static versions of every CPU model, define a
> > "base" CPU model that has absolutely no feature flag enabled.
> >
>
> Introducing separate ones makes feature lists presented to the user much
> shorter (and therefore easier to maintain). But I don't know how libvirt
> wants to deal with models on x86 in the future.
I understand that having a larger set of static models would make
expansions shorter. But I worry that by defining a complete set
of static models on x86 would require extra maintenance work on
the QEMU side with no visible benefit for libvirt.
I would like to hear from libvirt developers what they think. I
still don't know what they plan to use the type=static expansion
results for.
>
> How long is the static expansion on a recent intel CPU?
CPU model "Broadwell" returns 165 entries on return.model.props:
(QEMU) query-cpu-model-expansion type=static model={"name":"Broadwell"}
{"return": {"migration-safe": true, "model": {"name": "base", "props": {"pfthreshold": false, "pku": false, "rtm": true, "tsc-deadline": true, "xstore-en": false, "tsc-scale": false, "abm": true, "ia64": false, "kvm-mmu": false, "xsaveopt": true, "tce": false, "smep": true, "fpu": true, "xcrypt": false, "clflush": true, "flushbyasid": false, "kvm-steal-time": false, "lm": true, "tsc": true, "adx": true, "fxsr": true, "tm": false, "xgetbv1": false, "xstore": false, "vme": false, "vendor": "GenuineIntel", "arat": true, "de": true, "aes": true, "pse": true, "ds-cpl": false, "tbm": false, "sse": true, "phe-en": false, "f16c": true, "ds": false, "mpx": false, "tsc-adjust": false, "avx512f": false, "avx2": true, "pbe": false, "cx16": true, "avx512pf": false, "movbe": true, "perfctr-nb": false, "ospke": false, "avx512ifma": false, "stepping": 2, "sep": true, "sse4a": false, "avx512dq": false, "avx512-4vnniw": false, "xsave": true, "pmm": false, "hle": true, "est": false, "xop": false, "smx": false, "monitor": false, "avx512er": false, "apic": true, "sse4.1": true, "sse4.2": true, "pause-filter": false, "lahf-lm": true, "kvm-nopiodelay": false, "acpi": false, "mmx": true, "osxsave": false, "pcommit": false, "mtrr": true, "clwb": false, "dca": false, "pdcm": false, "xcrypt-en": false, "3dnow": false, "invtsc": false, "tm2": false, "hypervisor": true, "kvmclock-stable-bit": false, "fxsr-opt": false, "pcid": true, "lbrv": false, "avx512-4fmaps": false, "svm-lock": false, "popcnt": true, "nrip-save": false, "avx512vl": false, "x2apic": true, "kvmclock": false, "smap": true, "family": 6, "min-level": 13, "dtes64": false, "ace2": false, "fma4": false, "xtpr": false, "avx512bw": false, "nx": true, "lwp": false, "msr": true, "ace2-en": false, "decodeassists": false, "perfctr-core": false, "pge": true, "pn": false, "fma": true, "nodeid-msr": false, "cx8": true, "mce": true, "avx512cd": false, "cr8legacy": false, "mca": true, "pni": true, "rdseed": true, "osvw": false, "fsgsbase": true, "model-id": "Intel Core Processor (Broadwell)", "cmp-legacy": false, "kvm-pv-unhalt": false, "rdtscp": true, "mmxext": false, "cid": false, "vmx": false, "ssse3": true, "extapic": false, "pse36": true, "min-xlevel": 2147483656, "ibs": false, "avx": true, "syscall": true, "umip": false, "invpcid": true, "bmi1": true, "bmi2": true, "vmcb-clean": false, "erms": true, "cmov": true, "misalignsse": false, "clflushopt": false, "pat": true, "3dnowprefetch": true, "rdpid": false, "pae": true, "wdt": false, "skinit": false, "pmm-en": false, "phe": false, "3dnowext": false, "lmce": false, "ht": false, "pdpe1gb": false, "kvm-pv-eoi": false, "npt": false, "xsavec": false, "pclmulqdq": true, "svm": false, "sse2": true, "ss": false, "topoext": false, "rdrand": true, "avx512vbmi": false, "kvm-asyncpf": false, "xsaves": false, "model": 61}}, "static": true}}
--
Eduardo
7 years, 11 months
[libvirt] [PATCH 0/3] Get the voldef target physical value
by John Ferlan
This effort started primarily to address some ideas/thoughts brought
up in https://bugzilla.redhat.com/show_bug.cgi?id=1332019 although as
things were updated, it seems that using storage volume definitions
wouldn't be necessary since the same data can be obtained via the
virDomainGetBlockInfo API.
Still since code had been written - I figured I'd posted it and see
what kind of feedback it got.
The first patch just adds the <physical> element to the output XML
and documents it thusly.
The 2nd/3rd patch take a different approach adding virStorageVolInfoFlags
which could take a single flag indicating that the caller would prefer
to return the "physical" value instead of the "allocation" value. Yes,
kind of a hack, but since we cannot extend _virStorageVolInfo to add
a physical it's a mechanism to allow fetching the data using existing
structures. Sure a virStorageVolStats API could be created as well,
but I figured I'd see how this went first before thinking about that.
John Ferlan (3):
conf: Display <physical> in output of voldef
storage: Introduce virStorageVolInfoFlags
virsh: Allow display of the physical volume size
daemon/remote.c | 38 +++++++++++++++++++++++++++++
docs/formatstorage.html.in | 5 ++++
include/libvirt/libvirt-storage.h | 11 +++++++++
src/conf/storage_conf.c | 6 +++++
src/driver-storage.h | 6 +++++
src/libvirt-storage.c | 51 +++++++++++++++++++++++++++++++++++++++
src/libvirt_public.syms | 5 ++++
src/remote/remote_driver.c | 37 ++++++++++++++++++++++++++++
src/remote/remote_protocol.x | 20 ++++++++++++++-
src/remote_protocol-structs | 10 ++++++++
src/storage/storage_driver.c | 24 +++++++++++++++---
tools/virsh-volume.c | 37 +++++++++++++++++++++++++---
tools/virsh.pod | 8 ++++--
13 files changed, 247 insertions(+), 11 deletions(-)
--
2.7.4
7 years, 11 months
[libvirt] [PATCH 0/2] cgroup: unavailable controller prevents controller disabling
by Boris Fiuczynski
The problem description is covered in patch one.
I added patch two as an optional enhancement removing some complexity and
improving readability. If this finds common agreement it should simply be
squashed into the first patch of this series.
Boris Fiuczynski (2):
cgroup: unavailable controller prevents controller disabling
cgroup: reduce complexity of controller disabling
src/util/vircgroup.c | 15 ++++++++++-----
1 file changed, 10 insertions(+), 5 deletions(-)
--
2.5.5
7 years, 11 months
[libvirt] [PATCH] qemu: Adjust qemuDomainGetBlockInfo data for sparse backed files
by John Ferlan
According to commit id '0282ca45a' the 'physical' value should
essentially be the last offset of the image or the host physical
size in bytes of the image container. However, commit id '15fa84ac'
refactored the GetBlockInfo to use the same returned data as the
GetStatsBlock API for an active domain. For the 'entry->physical'
that would end up being the "actual-size" as set through the
qemuMonitorJSONBlockStatsUpdateCapacityOne (commit '7b11f5e5').
Digging deeper into QEMU code one finds that actual_size is
filled in using the same algorithm as GetBlockInfo has used for
setting the 'allocation' field when the domain is inactive.
The difference in values is seen primarily in sparse raw files
and other container type files (such as qcow2), which will return
a smaller value via the stat API for 'st_blocks'. Additionally
for container files, the 'capacity' field (populated via the
QEMU "virtual-size" value) may be slightly different (smaller)
in order to accomodate the overhead for the container. For
sparse files, the state 'st_size' field is returned.
This patch thus alters the allocation and physical values for
sparse backed storage files to be more appropriate to the API
contract. The result for GetBlockInfo is the following:
capacity: logical size in bytes of the image (how much storage
the guest will see)
allocation: host storage in bytes occupied by the image (such
as highest allocated extent if there are no holes,
similar to 'du')
physical: host physical size in bytes of the image container
(last offset, similar to 'ls')
NB: The GetStatsBlock API allows a different contract for the
values:
"block.<num>.allocation" - offset of the highest written sector
as unsigned long long.
"block.<num>.capacity" - logical size in bytes of the block device
backing image as unsigned long long.
"block.<num>.physical" - physical size in bytes of the container
of the backing image as unsigned long long.
Signed-off-by: John Ferlan <jferlan(a)redhat.com>
---
Initially based on a question posed on libvirt-users:
https://www.redhat.com/archives/libvirt-users/2016-November/msg00050.html
related to determining whether the provided physical value for an
inactive guest would be valid I found that virDomainGetBlockInfo was
returning different results for capacity and physical when the domain
was running. As I dug deeper I found Eric Blake's commit regarding how
libvirt uses/describes the allocation, capacity, and physical and felt
that the changes made to virDomainGetBlockInfo especially for sparse files
and "container" files (such as qcow2) would essentially provide incorrect
and perhaps unexpected results.
If it's felt that the live/active domain should return/display the same
as the virConnectGetAllDomainStats, then I can drop the patch. I guess I
find it odd that the physical size could be 4K matching the allocation
value for a sparse file. Likewise, for a fully preallocated file was
showing an allocation value of 0 since wr_highest_offset hadn't yet
been updated.
I've been testing with a guest with different types of "file" and "block"
storage backings where the 'block' storage is essentially iSCSI devices
added to the guest. Logically the changes result in what I'd expect for
results based upon reading the API docs.
src/qemu/qemu_driver.c | 22 +++++++++++++++++++---
1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index 88778d4..c537891 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -11808,13 +11808,29 @@ qemuDomainGetBlockInfo(virDomainPtr dom,
info->allocation = entry->wr_highest_offset;
}
- if (entry->physical) {
- info->physical = entry->physical;
- } else {
+ /* Unlike GetStatsBlock, this API has defined the expected return values
+ * for allocation and physical slightly differently.
+ *
+ * Having a zero for either or if they're the same is an indication that
+ * there's a sparse file backing this device. In this case, we'll force
+ * the setting of physical based on the on disk file size.
+ *
+ * Additionally, if qemu hasn't written to the file yet, then set the
+ * allocation to whatever qemu returned for physical (e.g. the "actual-
+ * size" from the json query) as that will match the expected allocation
+ * value for this API. */
+ if (entry->physical == 0 || info->allocation == 0 ||
+ info->allocation == entry->physical) {
+ info->allocation = entry->physical;
+ if (info->allocation == 0)
+ info->allocation = entry->physical;
+
if (qemuDomainStorageUpdatePhysical(driver, cfg, vm, disk->src) < 0)
goto endjob;
info->physical = disk->src->physical;
+ } else {
+ info->physical = entry->physical;
}
info->capacity = entry->capacity;
--
2.7.4
7 years, 11 months
[libvirt] [PATCH] examples: Resolve sign-compare warnings
by Michal Privoznik
For instance:
hellolibvirt/hellolibvirt.c: In function 'showDomains':
hellolibvirt/hellolibvirt.c:100:19: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
for (i = 0; i < numNames; i++) {
^
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
examples/admin/client_info.c | 2 +-
examples/admin/client_limits.c | 2 +-
examples/admin/list_clients.c | 2 +-
examples/admin/list_servers.c | 2 +-
examples/admin/threadpool_params.c | 2 +-
examples/domsuspend/suspend.c | 2 +-
examples/domtop/domtop.c | 7 +++----
examples/hellolibvirt/hellolibvirt.c | 2 +-
examples/openauth/openauth.c | 2 +-
9 files changed, 11 insertions(+), 12 deletions(-)
diff --git a/examples/admin/client_info.c b/examples/admin/client_info.c
index 314a0902b..57e9cd71e 100644
--- a/examples/admin/client_info.c
+++ b/examples/admin/client_info.c
@@ -102,7 +102,7 @@ int main(int argc, char **argv)
virAdmClientPtr clnt = NULL; /* which client get identity for */
virTypedParameterPtr params = NULL; /* where to store identity info */
int nparams = 0;
- size_t i = 0;
+ ssize_t i = 0;
char *timestr = NULL;
if (argc != 3) {
diff --git a/examples/admin/client_limits.c b/examples/admin/client_limits.c
index 2d5b75489..2a1d6314c 100644
--- a/examples/admin/client_limits.c
+++ b/examples/admin/client_limits.c
@@ -9,7 +9,7 @@ int main(int argc, char **argv)
virAdmServerPtr srv = NULL; /* which server to work with */
virTypedParameterPtr params = NULL;
int nparams = 0;
- size_t i;
+ ssize_t i;
if (argc != 2) {
fprintf(stderr, "One argument specifying the server which to work "
diff --git a/examples/admin/list_clients.c b/examples/admin/list_clients.c
index 3b4496e30..21ea4d818 100644
--- a/examples/admin/list_clients.c
+++ b/examples/admin/list_clients.c
@@ -50,7 +50,7 @@ int main(int argc, char **argv)
virAdmConnectPtr conn = NULL;
virAdmServerPtr srv = NULL; /* which server list the clients from */
virAdmClientPtr *clients = NULL; /* where to store the servers */
- size_t i = 0;
+ ssize_t i = 0;
int count = 0;
if (argc != 2) {
diff --git a/examples/admin/list_servers.c b/examples/admin/list_servers.c
index 1f6f4c6cf..420fd5fb7 100644
--- a/examples/admin/list_servers.c
+++ b/examples/admin/list_servers.c
@@ -8,7 +8,7 @@ int main(void)
virAdmConnectPtr conn = NULL;
virAdmServerPtr *servers = NULL; /* where to store the servers */
virAdmServerPtr *tmp = NULL;
- size_t i = 0;
+ ssize_t i = 0;
int count = 0;
/* first, open a connection to the daemon */
diff --git a/examples/admin/threadpool_params.c b/examples/admin/threadpool_params.c
index ee9ce83c1..43c71184a 100644
--- a/examples/admin/threadpool_params.c
+++ b/examples/admin/threadpool_params.c
@@ -9,7 +9,7 @@ int main(int argc, char **argv)
virAdmServerPtr srv = NULL; /* which server to work with */
virTypedParameterPtr params = NULL;
int nparams = 0;
- size_t i;
+ ssize_t i;
if (argc != 2) {
fprintf(stderr, "One argument specifying the server which to work "
diff --git a/examples/domsuspend/suspend.c b/examples/domsuspend/suspend.c
index 3e3f70e23..493a4b7b2 100644
--- a/examples/domsuspend/suspend.c
+++ b/examples/domsuspend/suspend.c
@@ -156,7 +156,7 @@ fetch_domains(virConnectPtr conn)
{
int num_domains, ret = -1;
virDomainPtr *domains = NULL;
- size_t i;
+ ssize_t i;
const int list_flags = VIR_CONNECT_LIST_DOMAINS_ACTIVE;
DEBUG("Fetching list of running domains");
diff --git a/examples/domtop/domtop.c b/examples/domtop/domtop.c
index 22839947d..5a798154a 100644
--- a/examples/domtop/domtop.c
+++ b/examples/domtop/domtop.c
@@ -161,7 +161,7 @@ fetch_domains(virConnectPtr conn)
{
int num_domains, ret = -1;
virDomainPtr *domains = NULL;
- size_t i;
+ ssize_t i;
const int list_flags = VIR_CONNECT_LIST_DOMAINS_ACTIVE;
DEBUG("Fetching list of running domains");
@@ -189,8 +189,7 @@ fetch_domains(virConnectPtr conn)
}
static void
-print_cpu_usage(const char *dom_name,
- size_t cpu,
+print_cpu_usage(size_t cpu,
size_t ncpus,
unsigned long long then,
virTypedParameterPtr then_params,
@@ -334,7 +333,7 @@ do_top(virConnectPtr conn,
goto cleanup;
}
- print_cpu_usage(dom_name, 0, max_id,
+ print_cpu_usage(0, max_id,
then.tv_sec * 1000000 + then.tv_usec,
then_params, then_nparams,
now.tv_sec * 1000000 + now.tv_usec,
diff --git a/examples/hellolibvirt/hellolibvirt.c b/examples/hellolibvirt/hellolibvirt.c
index c64fa9658..02c440198 100644
--- a/examples/hellolibvirt/hellolibvirt.c
+++ b/examples/hellolibvirt/hellolibvirt.c
@@ -55,7 +55,7 @@ static int
showDomains(virConnectPtr conn)
{
int ret = 0, numNames, numInactiveDomains, numActiveDomains;
- size_t i;
+ ssize_t i;
int flags = VIR_CONNECT_LIST_DOMAINS_ACTIVE |
VIR_CONNECT_LIST_DOMAINS_INACTIVE;
virDomainPtr *nameList = NULL;
diff --git a/examples/openauth/openauth.c b/examples/openauth/openauth.c
index 0be977ef8..7a8254bb1 100644
--- a/examples/openauth/openauth.c
+++ b/examples/openauth/openauth.c
@@ -91,7 +91,7 @@ static int
showDomains(virConnectPtr conn)
{
int ret = 0, numNames, numInactiveDomains, numActiveDomains;
- size_t i;
+ ssize_t i;
char **nameList = NULL;
numActiveDomains = virConnectNumOfDomains(conn);
--
2.11.0
7 years, 11 months
Re: [libvirt] [Qemu-ppc] [RFC PATCH qemu] spapr_pci: Create PCI-express root bus by default
by Andrea Bolognani
On Tue, 2016-11-01 at 13:46 +1100, David Gibson wrote:
> On Mon, Oct 31, 2016 at 03:10:23PM +1100, Alexey Kardashevskiy wrote:
> >
> > On 31/10/16 13:53, David Gibson wrote:
> > >
> > > On Fri, Oct 28, 2016 at 12:07:12PM +0200, Greg Kurz wrote:
> > > >
> > > > On Fri, 28 Oct 2016 18:56:40 +1100
> > > > Alexey Kardashevskiy <aik(a)ozlabs.ru> wrote:
> > > >
> > > > >
> > > > > At the moment sPAPR PHB creates a root buf of TYPE_PCI_BUS type.
> > > > > This means that vfio-pci devices attached to it (and this is
> > > > > a default behaviour) hide PCIe extended capabilities as
> > > > > the bus does not pass a pci_bus_is_express(pdev->bus) check.
> > > > >
> > > > > This changes adds a default PCI bus type property to sPAPR PHB
> > > > > and uses TYPE_PCIE_BUS if none passed; older machines get TYPE_PCI_BUS
> > > > > for backward compatibility as a bus type is used in the bus name
> > > > > so the root bus name becomes "pcie.0" instead of "pci.0".
> > > > >
> > > > > Signed-off-by: Alexey Kardashevskiy <aik(a)ozlabs.ru>
> > > > > ---
> > > > >
> > > > > What can possibly go wrong with such change of a name?
> > > > > From devices prospective, I cannot see any.
> > > > >
> > > > > libvirt might get upset as "pci.0" will not be available,
> > > > > will it make sense to create pcie.0 as a root bus and always
> > > > > add a PCIe->PCI bridge and name its bus "pci.0"?
> > > > >
> > > > > Or create root bus from TYPE_PCIE_BUS and force name to "pci.0"?
> > > > > pci_register_bus() can do this.
> > > > >
> > > > >
> > > > > ---
> > > > > hw/ppc/spapr.c | 5 +++++
> > > > > hw/ppc/spapr_pci.c | 5 ++++-
> > > > > include/hw/pci-host/spapr.h | 1 +
> > > > > 3 files changed, 10 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> > > > > index 0b3820b..a268511 100644
> > > > > --- a/hw/ppc/spapr.c
> > > > > +++ b/hw/ppc/spapr.c
> > > > > @@ -2541,6 +2541,11 @@ DEFINE_SPAPR_MACHINE(2_8, "2.8", true);
> > > > > .driver = TYPE_SPAPR_PCI_HOST_BRIDGE, \
> > > > > .property = "mem64_win_size", \
> > > > > .value = "0", \
> > > > > + }, \
> > > > > + { \
> > > > > + .driver = TYPE_SPAPR_PCI_HOST_BRIDGE, \
> > > > > + .property = "root_bus_type", \
> > > > > + .value = TYPE_PCI_BUS, \
> > > > > },
> > > > >
> > > > > static void phb_placement_2_7(sPAPRMachineState *spapr, uint32_t index,
> > > > > diff --git a/hw/ppc/spapr_pci.c b/hw/ppc/spapr_pci.c
> > > > > index 7cde30e..2fa1f22 100644
> > > > > --- a/hw/ppc/spapr_pci.c
> > > > > +++ b/hw/ppc/spapr_pci.c
> > > > > @@ -1434,7 +1434,9 @@ static void spapr_phb_realize(DeviceState *dev, Error **errp)
> > > > > bus = pci_register_bus(dev, NULL,
> > > > > pci_spapr_set_irq, pci_spapr_map_irq, sphb,
> > > > > &sphb->memspace, &sphb->iospace,
> > > > > - PCI_DEVFN(0, 0), PCI_NUM_PINS, TYPE_PCI_BUS);
> > > > > + PCI_DEVFN(0, 0), PCI_NUM_PINS,
> > > > > + sphb->root_bus_type ? sphb->root_bus_type :
> > > > > + TYPE_PCIE_BUS);
> > > >
> > > > Shouldn't we ensure that sphb->root_bus_type is either TYPE_PCIE_BUS or
> > > > TYPE_PCI_BUS ?
> > >
> > > Yes, I think so. In fact, I think it would be better to make the
> > > property a boolean that just selects PCI-E, rather than this which
> > > exposes qemu (semi-)internal type names on the comamnd line.
> >
> > Sure, a "pcie-root" boolean property should do.
> >
> > However this is not my main concern, I rather wonder if we have to have
> > pci.0 when we pick PCIe for the root.
>
> Right.
>
> I've added Andrea Bologna to the CC list to get a libvirt perspective.
Thanks for doing so: changes such as this one can have quite
an impact on the upper layers of the stack, so the earliest
libvirt is involved in the discussion the better.
I'm going to go a step further and cross-post to libvir-list
in order to give other libvirt contributors a chance to chime
in too.
> Andrea,
>
> To summarise the issue here:
> * As I've said before the PAPR spec kinda-sorta abstracts the
> difference between vanilla PCI and PCI-E
> * However, because within qemu we're declaring the bus as PCI that
> means some PCI-E devices aren't working right
> * In particular it means that PCI-E extended config space isn't
> available
>
> The proposal is to change (on newer machine types) the spapr PHB code
> to declare a PCI-E bus instead. AIUI this still won't make the root
> complex guest visible (which it's not supposed to be under PAPR), and
> the guest shouldn't see a difference in most cases - it will still see
> the PAPR abstracted PCIish bus, but will now be able to get extended
> config space.
>
> The possible problem from a libvirt perspective is that doing this in
> the simplest way in qemu would change the name of the default bus from
> pci.0 to pcie.0. We have two suggested ways to mitigate this:
> 1) Automatically create a PCI-E to PCI bridge, so that new machine
> types will have both a pcie.0 and pci.0 bus
> 2) Force the name of the bus to be pci.0, even though it's treated
> as PCI-E in other ways.
>
> We're trying to work out exactly what will and won't cause trouble for
> libvirt.
Option 2) is definitely a no-no, as we don't want to be piling
up even more hacks and architecture-specific code: the PCI
Express Root Bus should be called pcie.0, just as it is on q35
and mach-virt machine types.
Option 1) doesn't look too bad, but devices that are added
automatically by QEMU are an issue since we need to hardcode
knowledge of them into libvirt if we want the rest of the PCI
address allocation logic to handle them correctly.
Moreover libvirt now has the ability of building a legacy PCI
topology without user intervention, if needed to plug in
legacy devices, on machines that have a PCI Express Root Bus,
which makes the additional bridge fully redundant...
... or at least it would, if we actually had a proper
PCIe-to-PCI bridge; AFAIK, though, the closest we have is the
i82801b11-bridge that is Intel-specific despite having so far
been abused as a generic PCIe-to-PCI bridge. I'm not even
sure whether it would work at all on ppc64.
Moving from legacy PCI to PCI Express would definitely be an
improvement, in my opinion. As mentioned, that's already the
case for at least two other architectures, so the more we can
standardize on that, the better.
That said, considering that a big part of the PCI address
allocation logic is based off whether the specific machine
type exposes a legay PCI Root Bus or a PCI Express Root Bus,
libvirt will need a way to be able to tell which one is which.
Version checks are pretty much out of the question, as they
fail as soon as downstream releases enter the picture. A
few ways we could deal with the situation:
1) switch to PCI Express on newer machine types, and
expose some sort of capability through QMP so that
libvirt can know about the switch
2) switch between legacy PCI and PCI Express based on a
machine type option. libvirt would be able to find out
whether the option is available or not, and default to
either
<controller type='pci' model='pci-root'/>
or
<controller type='pci' model='pcie-root'/>
based on that. In order to support multiple PHBs
properly, those would have to be switchable with an
option as well
3) create an entirely new machine type, eg. pseries-pcie
or whatever someone with the ability to come up with
decent names can suggest :) That would make ppc64
similar to x86, where i440fx and q35 have different
root buses. libvirt would learn about the new machine
type, know that it has a PCI Express Root Bus, and
behave accordingly
Option 1) would break horribly with existing libvirt
versions, and so would Option 2) if we default to using
PCI Express. Option 2) with default to legacy PCI and
option 3) would work just fine with existing libvirt
versions AFAICT, but wouldn't of course expose the new
capabilities.
Option 3) is probably the one that will be less confusing
to users; we might even decide to take the chance and fix
other small annoyances with the current pseries machine
type, if there's any. On the other hand, it might very well
be considered to be too big a hammer for such a small nail.
--
Andrea Bolognani / Red Hat / Virtualization
7 years, 11 months
[libvirt] [PATCH] Point to the new libvirt-go bindings
by Daniel P. Berrange
The github.com/rgbkrk/libvirt-go bindings were the most complete
bindings historically, but their API coverage stops at 1.2.4,
with exception of a couple of newer APIs.
The new bindings at http://libvirt.org/git/?p=libvirt-go.git;a=log
how have (almost[1]) 100% API coverage all the way to 2.5.0. They also
expose the APIs in a way that allows for much stronger go type
checking by the compiler, and expose typed parameters as explicit
structs. Finally the bindings are able to conditionally compile against
any libvirt version 1.2.0 -> 2.5.0 without use of go build tags.
Change the docs to point to these new bindings, since they'll be
a better bet for users long term.
[1] virEvent & virStream callbacks are still TODO to be fixed
real soon.
Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com>
---
docs/bindings.html.in | 4 ++--
docs/docs.html.in | 2 +-
docs/downloads.html.in | 15 +++++++++++++++
3 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/docs/bindings.html.in b/docs/bindings.html.in
index 7fe26df..dc15576 100644
--- a/docs/bindings.html.in
+++ b/docs/bindings.html.in
@@ -15,8 +15,8 @@
<a href="csharp.html">C# bindings</a>.
</li>
<li>
- <strong>Go</strong>: Kyle Kelley et al. are developing
- <a href="https://github.com/rgbkrk/libvirt-go">Go bindings</a>.
+ <strong>Go</strong>: Daniel Berrange develops
+ <a href="https://godoc.org/github.com/libvirt/libvirt-go">Go bindings</a>.
</li>
<li>
<strong>Java</strong>: Daniel Veillard develops
diff --git a/docs/docs.html.in b/docs/docs.html.in
index b0d200b..60489a0 100644
--- a/docs/docs.html.in
+++ b/docs/docs.html.in
@@ -57,7 +57,7 @@
<dt><a href="bindings.html">Language bindings</a></dt>
<dd>Bindings of the libvirt API for
<a href="csharp.html">c#</a>,
- <a href="https://github.com/rgbkrk/libvirt-go">go</a>,
+ <a href="https://godoc.org/github.com/libvirt/libvirt-go">go</a>,
<a href="java.html">java</a>,
<a href="http://libvirt.org/ocaml/">ocaml</a>.
<a href="http://search.cpan.org/dist/Sys-Virt/">perl</a>,
diff --git a/docs/downloads.html.in b/docs/downloads.html.in
index dd96409..3a6ea91 100644
--- a/docs/downloads.html.in
+++ b/docs/downloads.html.in
@@ -57,6 +57,21 @@
</td>
</tr>
<tr>
+ <td>Go</td>
+ <td>
+ <a href="ftp://libvirt.org/libvirt/go/">ftp</a>
+ <a href="http://libvirt.org/sources/go/">http</a>
+ <a href="https://libvirt.org/sources/go/">https</a>
+ </td>
+ <td>
+ <a href="http://libvirt.org/git/?p=libvirt-go.git;a=summary">libvirt</a>
+ </td>
+ <td>
+ <a href="https://gitlab.com/libvirt/libvirt-go">gitlab</a>
+ <a href="https://github.com/libvirt/libvirt-go">github</a>
+ </td>
+ </tr>
+ <tr>
<td>Java</td>
<td>
<a href="ftp://libvirt.org/libvirt/java/">ftp</a>
--
2.9.3
7 years, 11 months
[libvirt] [PATCH] xen: add QED format test
by Cédric Bosdonnat
Follow up of commit 340bb6b7 to add unit tests for the QED format
support. Also add missing QED case in xenFormatXLDisk()
---
src/xenconfig/xen_xl.c | 5 +++++
tests/xlconfigdata/test-disk-positional-parms-full.cfg | 2 +-
tests/xlconfigdata/test-disk-positional-parms-full.xml | 6 ++++++
3 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/src/xenconfig/xen_xl.c b/src/xenconfig/xen_xl.c
index 048ecd579..65d8ffc63 100644
--- a/src/xenconfig/xen_xl.c
+++ b/src/xenconfig/xen_xl.c
@@ -1050,6 +1050,11 @@ xenFormatXLDisk(virConfValuePtr list, virDomainDiskDefPtr disk)
case VIR_STORAGE_FILE_QCOW2:
virBufferAddLit(&buf, "qcow2");
break;
+#ifdef LIBXL_HAVE_QED
+ case VIR_STORAGE_FILE_QED:
+ virBufferAddLit(&buf, "qed");
+ break;
+#endif
/* set default */
default:
virBufferAddLit(&buf, "raw");
diff --git a/tests/xlconfigdata/test-disk-positional-parms-full.cfg b/tests/xlconfigdata/test-disk-positional-parms-full.cfg
index 217d4dccf..20421ffc1 100644
--- a/tests/xlconfigdata/test-disk-positional-parms-full.cfg
+++ b/tests/xlconfigdata/test-disk-positional-parms-full.cfg
@@ -22,4 +22,4 @@ parallel = "none"
serial = "none"
builder = "hvm"
boot = "d"
-disk = [ "/dev/HostVG/XenGuest2,raw,hda,rw,backendtype=phy", "/var/lib/libvirt/images/XenGuest2-home,qcow2,hdb,rw", "/root/boot.iso,raw,hdc,ro,devtype=cdrom" ]
+disk = [ "/dev/HostVG/XenGuest2,raw,hda,rw,backendtype=phy", "/var/lib/libvirt/images/XenGuest2-home,qcow2,hdb,rw", "/root/boot.iso,raw,hdc,ro,devtype=cdrom", "/var/lib/libvirt/images/XenGuest2-qed,qed,hdd,rw", ]
diff --git a/tests/xlconfigdata/test-disk-positional-parms-full.xml b/tests/xlconfigdata/test-disk-positional-parms-full.xml
index 1bc5b436e..9c2fb41b7 100644
--- a/tests/xlconfigdata/test-disk-positional-parms-full.xml
+++ b/tests/xlconfigdata/test-disk-positional-parms-full.xml
@@ -39,6 +39,12 @@
<readonly/>
<address type='drive' controller='0' bus='1' target='0' unit='0'/>
</disk>
+ <disk type='file' device='disk'>
+ <driver name='qemu' type='qed'/>
+ <source file='/var/lib/libvirt/images/XenGuest2-qed'/>
+ <target dev='hdd' bus='ide'/>
+ <address type='drive' controller='0' bus='1' target='0' unit='1'/>
+ </disk>
<controller type='ide' index='0'/>
<interface type='bridge'>
<mac address='00:16:3e:66:92:9c'/>
--
2.11.0
7 years, 11 months
[libvirt] [PATCH] docs: link to news file and other resources
by Daniel P. Berrange
In the website reorg we accidentally lost all links to the nice
reformatted news.html file. Add a link on the front page, and
also extend the download page table so that it includes links
to API docs and news files for each module (where available)
Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com>
---
docs/downloads.html.in | 12 ++++++++++++
docs/index.html.in | 1 +
2 files changed, 13 insertions(+)
diff --git a/docs/downloads.html.in b/docs/downloads.html.in
index 3a6ea91..d56e17b 100644
--- a/docs/downloads.html.in
+++ b/docs/downloads.html.in
@@ -20,6 +20,7 @@
<th>Releases</th>
<th>GIT Repo</th>
<th>GIT Mirrors</th>
+ <th>Resources</th>
</tr>
</thead>
<tbody>
@@ -37,6 +38,10 @@
<a href="https://gitlab.com/libvirt/libvirt">gitlab</a>
<a href="https://github.com/libvirt/libvirt">github</a>
</td>
+ <td>
+ <a href="html/index.html">api ref</a>
+ <a href="news.html">changes</a>
+ </td>
</tr>
<tr>
<th colspan="7">Language bindings</th>
@@ -70,6 +75,9 @@
<a href="https://gitlab.com/libvirt/libvirt-go">gitlab</a>
<a href="https://github.com/libvirt/libvirt-go">github</a>
</td>
+ <td>
+ <a href="https://godoc.org/github.com/libvirt/libvirt-go">api ref</a>
+ </td>
</tr>
<tr>
<td>Java</td>
@@ -113,6 +121,10 @@
<a href="https://gitlab.com/libvirt/libvirt-perl">gitlab</a>
<a href="https://github.com/libvirt/libvirt-perl">github</a>
</td>
+ <td>
+ <a href="http://search.cpan.org/dist/Sys-Virt/">api ref</a>
+ <a href="http://libvirt.org/git/?p=libvirt-perl.git;a=blob;f=Changes;hb=HEAD">changes</a>
+ </td>
</tr>
<tr>
<td>PHP</td>
diff --git a/docs/index.html.in b/docs/index.html.in
index bcb47f7..31bd6e0 100644
--- a/docs/index.html.in
+++ b/docs/index.html.in
@@ -41,6 +41,7 @@
<li>targets Linux, FreeBSD, <a href="windows.html">Windows</a> and OS-X</li>
<li>is used by many <a href="apps.html">applications</a></li>
</ul>
+ <p>Recent / forthcoming <a href="news.html">release changes</a></p>
</div>
<div class="panel">
--
2.9.3
7 years, 11 months
