[PATCH 0/2] Use netlink to create veth device pair when netlink is
by Shi Lei
When netlink and libnl are supported, use it to create veth device pair.
Shi Lei (2):
util:netlink: Enable virNetlinkNewLink to support veth
util:veth: Create veth device pair by netlink
src/util/virnetdevveth.c | 39 ++++++++++++++++++++++++++++++---------
src/util/virnetlink.c | 25 +++++++++++++++++++++++++
src/util/virnetlink.h | 1 +
3 files changed, 56 insertions(+), 9 deletions(-)
--
2.25.1
4 years, 1 month
[libvirt PATCH] qemu: fix setting of scsi-id for ESP SCSI controllers
by Daniel P. Berrangé
The ESP SCSI controllers have same requirement as the LSI Logic
controller for each disk to be set via the scsi-id=NNN property,
not the lun=NNN property.
Switching the code to use an enum will force authors to pay attention
to this difference when adding future SCSI controllers.
Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com>
---
src/qemu/qemu_command.c | 26 +++++++++++++++++++++--
tests/qemuxml2argvdata/sparc-minimal.args | 4 ++--
2 files changed, 26 insertions(+), 4 deletions(-)
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index fbaacb8dd8..479bcc0b0c 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_command.c
@@ -1625,17 +1625,39 @@ qemuBuildDiskDeviceStr(const virDomainDef *def,
disk->info.addr.drive.controller)))
return NULL;
- if (controllerModel == VIR_DOMAIN_CONTROLLER_MODEL_SCSI_LSILOGIC) {
+ switch ((virDomainControllerModelSCSI)controllerModel) {
+ case VIR_DOMAIN_CONTROLLER_MODEL_SCSI_LSILOGIC:
+ case VIR_DOMAIN_CONTROLLER_MODEL_SCSI_NCR53C90:
+ case VIR_DOMAIN_CONTROLLER_MODEL_SCSI_DC390:
+ case VIR_DOMAIN_CONTROLLER_MODEL_SCSI_AM53C974:
virBufferAsprintf(&opt, ",bus=%s.%d,scsi-id=%d",
contAlias,
disk->info.addr.drive.bus,
disk->info.addr.drive.unit);
- } else {
+ break;
+
+ case VIR_DOMAIN_CONTROLLER_MODEL_SCSI_AUTO:
+ case VIR_DOMAIN_CONTROLLER_MODEL_SCSI_BUSLOGIC:
+ case VIR_DOMAIN_CONTROLLER_MODEL_SCSI_LSISAS1068:
+ case VIR_DOMAIN_CONTROLLER_MODEL_SCSI_VMPVSCSI:
+ case VIR_DOMAIN_CONTROLLER_MODEL_SCSI_IBMVSCSI:
+ case VIR_DOMAIN_CONTROLLER_MODEL_SCSI_VIRTIO_SCSI:
+ case VIR_DOMAIN_CONTROLLER_MODEL_SCSI_LSISAS1078:
+ case VIR_DOMAIN_CONTROLLER_MODEL_SCSI_VIRTIO_TRANSITIONAL:
+ case VIR_DOMAIN_CONTROLLER_MODEL_SCSI_VIRTIO_NON_TRANSITIONAL:
virBufferAsprintf(&opt, ",bus=%s.0,channel=%d,scsi-id=%d,lun=%d",
contAlias,
disk->info.addr.drive.bus,
disk->info.addr.drive.target,
disk->info.addr.drive.unit);
+ break;
+
+ case VIR_DOMAIN_CONTROLLER_MODEL_SCSI_DEFAULT:
+ case VIR_DOMAIN_CONTROLLER_MODEL_SCSI_LAST:
+ virReportError(VIR_ERR_INTERNAL_ERROR,
+ _("Unexpected SCSI controller model %d"),
+ controllerModel);
+ return NULL;
}
if (scsiVPDDeviceId)
diff --git a/tests/qemuxml2argvdata/sparc-minimal.args b/tests/qemuxml2argvdata/sparc-minimal.args
index 65cf99c895..0bf4c8f825 100644
--- a/tests/qemuxml2argvdata/sparc-minimal.args
+++ b/tests/qemuxml2argvdata/sparc-minimal.args
@@ -26,9 +26,9 @@ path=/tmp/lib/domain--1-redhat62sparc/monitor.sock,server,nowait \
-usb \
-drive file=/home/berrange/VirtualMachines/redhat-6.2-sparc.img,format=qcow2,\
if=none,id=drive-scsi0-0-0-0 \
--device scsi-hd,bus=scsi.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,\
+-device scsi-hd,bus=scsi.0,scsi-id=0,drive=drive-scsi0-0-0-0,\
id=scsi0-0-0-0,bootindex=1 \
-drive file=/home/berrange/VirtualMachines/redhat-6.2-sparc.iso,format=raw,\
if=none,id=drive-scsi0-0-0-1,readonly=on \
--device scsi-cd,bus=scsi.0,channel=0,scsi-id=0,lun=1,drive=drive-scsi0-0-0-1,\
+-device scsi-cd,bus=scsi.0,scsi-id=1,drive=drive-scsi0-0-0-1,\
id=scsi0-0-0-1
--
2.28.0
4 years, 1 month
[PATCH-for-5.2 0/4] docs/system/arm: Document raspi/tosa boards
by Philippe Mathieu-Daudé
- Deprecate raspi2/raspi3 machine aliases
- Document the Raspberry Pi boards
- Document LED on OpenPOWER Witherspoon
- Document Sharp Zaurus SL-6000 Tosa
Philippe Mathieu-Daudé (4):
docs/system: Deprecate raspi2/raspi3 machine aliases
docs/system/arm: Document the various raspi boards
docs/system/arm: Document OpenPOWER Witherspoon BMC model Front LEDs
docs/system/arm: Document the Sharp Zaurus SL-6000
docs/system/arm/aspeed.rst | 1 +
docs/system/arm/raspi.rst | 44 ++++++++++++++++++++++++++++++++++++++
docs/system/arm/xscale.rst | 13 ++++++-----
docs/system/deprecated.rst | 7 ++++++
docs/system/target-arm.rst | 1 +
5 files changed, 61 insertions(+), 5 deletions(-)
create mode 100644 docs/system/arm/raspi.rst
--
2.26.2
4 years, 1 month
[libvirt PATCH 0/2] coverity patches
by Pavel Hrdina
Pavel Hrdina (2):
src: rework static analysis detection
gitlab-ci: add coverity job
.gitlab-ci.yml | 20 ++++++++++++++++++++
ci/containers/README.rst | 22 ++++++++++++++++++++++
meson.build | 14 --------------
src/internal.h | 4 ++++
4 files changed, 46 insertions(+), 14 deletions(-)
--
2.26.2
4 years, 1 month
Re: [PATCH 5/6] qapi: Add support for aliases
by Kevin Wolf
Am 12.11.2020 um 19:34 hat Eric Blake geschrieben:
> On 11/12/20 11:28 AM, Kevin Wolf wrote:
> > Introduce alias definitions for object types (structs and unions). This
> > allows using the same QAPI type and visitor for many syntax variations
> > that exist in the external representation, like between QMP and the
> > command line. It also provides a new tool for evolving the schema while
> > maintaining backwards compatibility during a deprecation period.
>
> Cool! Obvious followup patch series: deprecate all QAPI members spelled
> with _ by making them aliases of new members spelled with -, so that we
> can finally have consistent spellings.
Ah, that's a nice one, too. I didn't even think of it. Another one I'd
like to see is deprecation of SocketAddressLegacy.
There is one part missing in this series that we would first need to
address before we can actually use it to evolve parts of the schema that
are visible in QMP: Exposing aliases in introspection and expressing
that the original name of something is deprecated, but the alias will
stay around (and probably also deprecating an alias without the original
name or other aliases).
If we can easily figure out a way to express this that everyone agrees
with, I'm happy to include it in this series. Otherwise, since the first
user is the command line and not QMP, I'd leave that for the future.
For example, imagine we have an option 'foo' with a new alias 'bar'. If
we just directly expose the alias rule (which would be the simplest
solution from the QEMU perspective), management will check if the alias
exists before accessing 'bar'. But in the final state, we remove 'foo'
and 'bar' is not an alias any more, so the introspection for 'bar' would
change. Is this desirable?
On the other hand, we can't specify both as normal options because you
must set (at most) one of them, but not both. Also exposing things as
normal options becomes hard with wildcard aliases (mapping all fields
from a nested struct), especially if unions are involved where some
options exist in one or two variants, but not in others.
Given this, I think just exposing the alias rules and letting the
management tool check both alternatives - if the alias rule or the
future option exists - might actually still be the least bad option.
Hmm, I guess I should CC libvirt for this discussion, actually. :-)
> > +=== Aliases ===
> > +
> > +Object types, including structs and unions, can contain alias
> > +definitions.
> > +
> > +Aliases define alternative member names that may be used in the
> > +external representation to provide a value for a member in the same
> > +object or in a nested object.
> > +
> > +Syntax:
> > + ALIAS = { '*alias': STRING,
> > + 'source': [ STRING, ... ] }
> > +
> > +'source' is a list of member names representing the path to an object
> > +member, starting from the type where the alias definition is
> > +specified. It may refer to another alias name. It is allowed to use
> > +a path that doesn't necessarily match an existing member in every
> > +variant or even at all; in this case, the alias remains unused.
> > +
> > +If 'alias' is present, then the single member referred to by 'source'
> > +is made accessible with the name given in 'alias' in the type where
> > +the alias definition is specified.
> > +
> > +If 'alias' is not present, then all members in the object referred to
> > +by 'source' are made accessible in the type where the alias definition
> > +is specified with the same name as they have in 'source'.
>
> Is it worth an example of how to use this?
Yes, I should have included an example. Or actually, probably one
example for aliasing a single field and another one for a wildcard alias
that maps all fields in a struct.
Kevin
4 years, 1 month
[libvirt PATCH 0/2] coverity unchecked returns
by Ján Tomko
For #2, eventually we'd convert QEMUCaps to g_object and fix
all the copy functions, but that's too big of a yak to shave now.
Ján Tomko (2):
qemu: json: check return value of virJSONValueObjectGetBoolean
testsutilsqemu: check return value of virQEMUCapsNewCopy
src/qemu/qemu_monitor_json.c | 6 ++++--
tests/testutilsqemu.c | 3 +++
2 files changed, 7 insertions(+), 2 deletions(-)
--
2.26.2
4 years, 1 month
Availability of physical devices and migration (was: Re: [RFC PATCH 2/2] vfio-ccw: Connect the device request notifier)
by Cornelia Huck
On Fri, 20 Nov 2020 03:51:07 +0100
Halil Pasic <pasic(a)linux.ibm.com> wrote:
> On Tue, 17 Nov 2020 04:26:05 +0100
> Eric Farman <farman(a)linux.ibm.com> wrote:
>
> > Now that the vfio-ccw code has a notifier interface to request that
> > a device be unplugged, let's wire that together.
>
> I'm aware of the fact that performing an unplug is what vfio-pci does,
> but I was not aware of this before, and I became curious with regards
> to how is this going to mesh with migration (in the future).
>
> The sentence 'For this to work, QEMU has to be launched with the same
> arguments the two times.' form docs/devel/migration.rst should not
> be taken literally, I know, but the VM configuration changing not because
> it was changed via a management interface, but because of events that
> may not be under the control of whoever is managing the VM does
> make thinks harder to reason about.
>
> I suppose, we now basically mandate that whoever manages the VM, either
> a) maintains his own model of the VM and listens to the events, to
> update it if such a device removal happens, or
> b) inspects the VM at some appropriate point in time, to figure out how
> the target VM is supposed to be started.
>
> I think libvirt does a).
This seems like something that would be of general interest to libvirt
folks, adding the list on cc:.
For virtual devices, QEMU and any management software are in full
control, and can simply make sure that both source and target have the
device available.
For physical devices, we still can make sure that source and target
match when we do the setup, but device failures can happen at
inconvenient times. It may suddenly be no longer possible to access
state etc. Can we propagate changes like "device foobar, don't bother
migrating" even when we already started migration? Should the handling
be different if the target system uses a different (compatible) device?
Should we fail the migration?
>
> I also suppose, such a device removal may not happen during device
> migration. That is, form the QEMU perspective I believe taken care
> by the BQL.
Even if the device is not actually removed, it might still be
inaccessible.
>
> But I'm in the dark regarding the management software/libivrt view. For
> example what happens if we get a req_notification on the target while
> pre-copy memory migration? At that point the destination is already
> receiving pages, thus it is already constructed.
>
> My questions are not necessarily addressed to you Eric. Maybe the
> folks working on vfio migration can help us out. I'm also adding
> our libvirt guys.
>
> Regards,
> Halil
>
4 years, 1 month
[PATCH 00/16] virsh: Add support for network disks to --attach-disk
by Peter Krempa
This version refactors cmdAttachDisk first so that we can use a much
simpler logic to format the XML.
With the simpler logic and tests the code now doesn't misformat the XML
in certain situations as it was with the previous posting:
virsh attach-disk --print-xml --domain ble --source "asdfsource" --target "tgt"
>
<source dev='asdfsource'/>
<target dev='tgt'/>
</disk>
I've rather rewrote how we do things than trying to investigate why the
original version [1] failed.
The new version also adds tests so it's simpler to see that things
actually work.
[1] https://www.redhat.com/archives/libvir-list/2020-November/msg01071.html
Peter Krempa (15):
tests: virsh: Add simple testsuite for using --print-xml of various
commands
virsh: cmdAttachDisk: Declare one variable per line
virsh: cmdAttachDisk: Use automatic memory clearing for 'xml' and
'dom'
virsh: cmdAttachDisk: Refactor control flow
virsh: cmdAttachDisk: Don't assume type='block' if file can't be
examined
virsh: cmdAttachDisk: Split out formatting of disk address
virsh: Extract address formatting from cmdAttachDiskFormatAddress
virsh: Unify code for <address type='drive'
virsh: Refactor str2DiskAddress
virsh: Rename 'struct DiskAddress' and friends
virsh: virshAddress*: Move out of cmdAttachDisk block
virsh: cmdAttachDisk: Use enum for disk source type
virsh: cmdAttachDisk: Use virXMLFormatElement
tests: virsh-output: Mark as expensive
tests: virsh-checkpoint/snapshot: Mark as expensive
Ryan Gahagan (1):
virsh: Added attach-disk support for network disk
docs/manpages/virsh.rst | 31 +-
tests/meson.build | 1 +
tests/virsh-checkpoint | 2 +
tests/virsh-output | 29 ++
tests/virsh-output-commands | 94 +++++
tests/virsh-output.out | 496 ++++++++++++++++++++++++
tests/virsh-snapshot | 2 +
tools/virsh-domain.c | 748 ++++++++++++++++++------------------
8 files changed, 1017 insertions(+), 386 deletions(-)
create mode 100755 tests/virsh-output
create mode 100755 tests/virsh-output-commands
create mode 100644 tests/virsh-output.out
--
2.28.0
4 years, 1 month
