newer. Sorry for overlooking this.
> > I'd be okay with dropping it, but I leave the decision
> > to Gerd.
>
> Please leave it in for qemu-emulated.cfg, as this is supposed to serve
> as documentation how real q35 hardware looks like.
>
> From the virtio variants
> Matter of taste really. I have some guests where the vga is at 04.0,
> works fine too. But being consistent across all configurations makes
> sense.
Cool, I will stick to 00:01.0 across the board then.
--
Andrea Bolognani / Red Hat / Virtualization
Instead of having a single sample configuration file,
we now have several:
* q35-emulated.cfg documents the default devices QEMU
adds to a q35 guest and the additional devices that
are pretty much guaranteed to be present in a
physical q35-based machine;
* q35-virtio-graphical.cfg
These are very much like the sample configuration files
for q35, and can be used both as documentation and as
a starting point for creating your own guest.
Two sample configuration files are provided:
* mach-virt-graphical.cfg can be used to start a
fully-featured (USB, graphical console, e
inaccurate statement I might have made about AAVMF.
Andrea Bolognani (2):
q35: Improve sample configuration files
mach-virt: Provide sample configuration files
docs/mach-virt-graphical.cfg | 245 ++
docs/mach-virt-serial.cfg
Instead of having a single sample configuration file,
we now have several:
* q35-emulated.cfg documents the default devices QEMU
adds to a q35 guest and the additional devices that
are pretty much guaranteed to be present in a
physical q35-based machine;
* q35-virtio-graphical.cfg
ch64/QEMU_VARS.fd (template)
#
# RHELSA:
# AAVMF (package)
# /usr/share/AAVMF/AAVMF_CODE.fd(binary)
# /usr/share/AAVMF/AAVMF_VARS.fd(varstore)
--
Andrea Bolognani / Red Hat / Virtualization
using virtconsole here (and in q35*serial.cfg)
mostly to have as much VirtIO as possible, but I also
document the fact that you might want or need to use the
native serial console instead.
Moreover, something that I haven't been able to do on
mach-virt (even though I could on q35, but again, I wan
; - Again, the files you note above for Fedora are 2MB and 768KB in size,
> respectively, which is wrong. The files you note for RHELSA are both
> 64MB in size, which is right. Fedora ships the according files as well,
> but their names are different:
>
> /usr/share/edk2/aarch6
ces that
will always be present are:
00:00.0 Host bridge
This configuration file adds a number of other...
work for you? Please keep in mind that I want to be able
to use the very same paragraph both for q35 and mach-virt.
--
Andrea Bolognani / Red Hat / Virtualization
gt; > -- no clue. Ask Drew :))
>
> The first choice "RHEL" is correct. "RHELSA" still exists today,
> but eventually that name should be phased out (IIUC), as AArch64
> will be "just another RHEL arch", requiring no special name.
Can't wait for that day! I'll leave it unchanged then :)
--
Andrea Bolognani / Red Hat / Virtualization
uld be using
> the PL011 instead. We should also set it up such that the
> monitor is multiplexed, so ^C won't terminate the guest and
> ^A will allow us to go to the monitor.
That sounds awesome, how do I actually make it work from
the configuration file though?
[1] Looks like these files are not being installed on the
system by 'make install'. I'd argue having them in
/usr/share/doc/qemu/examples would be nice for users.
--
Andrea Bolognani / Red Hat / Virtualization
k of boot output and especially
GRUB menu access in virtconsole is less then ideal, because
even though the users will eventually get a login prompt,
the first few seconds without any output at all might lead
them to believe the guest is not working properly.
I just wish there were a way to add the default serial
console straight from the configuration file...
--
Andrea Bolognani / Red Hat / Virtualization
EMU :)
By the way, switching between serial and monitor is not
done with Ctrl+A but with Ctrl+A-c, which is not the most
convenient shortcut if you're running your guests on a
remote host due to GNU screen using the very same one ;)
--
Andrea Bolognani / Red Hat / Virtualization
t;
> BTW, when I stated "-nodefaults provides us a base mach-virt
> board with no peripherals.", I meant no _additional_
> peripherals plugged into the board's virtio-mmio transports,
> nor hung off the host bridge. Is there a word for those?
> Maybe just non-builtin peripherals?
Please propose the alternative wording you'd like to see
so we can discuss it :)
--
Andrea Bolognani / Red Hat / Virtualization
file adds a number of other...
Does it look acceptable?
--
Andrea Bolognani / Red Hat / Virtualization
On Thu, 2017-02-09 at 17:36 +0100, Andrew Jones wrote:
> On Thu, Feb 09, 2017 at 05:11:38PM +0100, Andrea Bolognani wrote:
> >
> > On Thu, 2017-02-09 at 16:35 +0100, Andrew Jones wrote:
> > >
> > > >
> > > > Please propose the alternative wordin
tml
[v5] http://lists.nongnu.org/archive/html/qemu-devel/2017-02/msg01714.html
Andrea Bolognani (2):
q35: Improve sample configuration files
mach-virt: Provide sample configuration files
docs/mach-virt-graphical.cfg | 262
Instead of having a single sample configuration file,
we now have several:
* q35-emulated.cfg documents the default devices QEMU
adds to a q35 guest and the additional devices that
are pretty much guaranteed to be present in a
physical q35-based machine;
* q35-virtio-graphical.cfg
These are very much like the sample configuration files
for q35, and can be used both as documentation and as
a starting point for creating your own guest.
Two sample configuration files are provided:
* mach-virt-graphical.cfg can be used to start a
fully-featured (USB, graphical console, e
GTK+ *in RHEL-7* specifically, I'm uncertain.
> But, I digress; no need to do anything about this.
GTK+ just seems to be the default display mode, so no
preference of my own really - although I have no problem
admitting that I'm a massive GNOME fan ;)
Calling out GTK+ explicitly here does not serve any purpose,
though, so I'll change it to a more neutral wording.
--
Andrea Bolognani / Red Hat / Virtualization
ml/qemu-devel/2017-02/msg00184.html
[v3] http://lists.nongnu.org/archive/html/qemu-devel/2017-02/msg00461.html
[v4] http://lists.nongnu.org/archive/html/qemu-devel/2017-02/msg00672.html
[v5] http://lists.nongnu.org/archive/html/qemu-devel/2017-02/msg01714.html
[v6] http://lists.nongnu.org/archive/
Instead of having a single sample configuration file,
we now have several:
* q35-emulated.cfg documents the default devices QEMU
adds to a q35 guest and the additional devices that
are pretty much guaranteed to be present in a
physical q35-based machine;
* q35-virtio-graphical.cfg
These are very much like the sample configuration files
for q35, and can be used both as documentation and as
a starting point for creating your own guest.
Two sample configuration files are provided:
* mach-virt-graphical.cfg can be used to start a
fully-featured (USB, graphical console, e
r qemu.* not to do
the same; in particular, using a version number that's not <1.0.0 for
a package that is very much in flux will almost certainly break
people's expectations, and is also not something that you can easily
take back at a later time.
--
Andrea Bolognani / Red Hat / Virtualization
On Mon, 2020-10-19 at 11:02 +0100, Daniel P. Berrangé wrote:
> On Mon, Oct 19, 2020 at 11:45:09AM +0200, Andrea Bolognani wrote:
> > I think this need to be considered very carefully.
> >
> > I'm not overly familiar with the Python ecosystem but it would appear
>
be updating both QEMU & Python together.
Once you start uploading the Python packages to PyPi, you really have
no way to ensure this will be the case.
--
Andrea Bolognani / Red Hat / Virtualization
on'] == 'CentOS'"
> +- "ansible_facts['distribution_major_version'] == '8'"
Another option would be to use
command: 'dnf config-manager --set-enabled Stream-PowerTools -y'
args:
warn: no
but I have to admit the way you're doing it is very clever ;)
--
Andrea Bolognani / Red Hat / Virtualization
t by just automating creation of the package lists that
> the tests/vm and ansibile recipes need, as again those are all
> inconsistent.
Perhaps 'lcitool variables' could be of use here.
--
Andrea Bolognani / Red Hat / Virtualization
oldest dropped from
> our side) we can add/remove a column and see the oldest version we aim
> to support.
In case you're not already aware of it, https://repology.org/ is a
very valuable tool when it comes to figuring out minimum versions for
dependencies.
--
Andrea Bolognani / Red Hat / Virtualization
, to the best of our knowledge, all accurate,
some parts are in a rougher state than others. Improvements will
hopefully come over time - and if you feel like helping out in making
that happen, it would certainly be appreciated!
Looking forward to your feedback :)
[1] https://gitlab.com/abologna/kubevir
https://gitlab.com/abologna/kubevirt-and-kvm/-/blob/master/Index.md
# KubeVirt and the KVM user space
This is the entry point to a series of documents which, together,
detail the current status of KubeVirt and how it interacts with the
KVM user space.
The intended audience is people who are fami
https://gitlab.com/abologna/kubevirt-and-kvm/-/blob/master/Storage.md
# Storage
This document describes the known use-cases and architecture options
we have for Linux Virtualization storage in [KubeVirt][].
## Problem description
The main goal of Kubevirt is to leverage the storage subsystem of
https://gitlab.com/abologna/kubevirt-and-kvm/-/blob/master/Hotplug.md
# Hotplug
In Kubernetes, pods are defined to be immutable, so it's not possible
to perform hotplug of devices in the same way as with the traditional
virtualization stack.
This limitation is a result of KubeVirt's guiding prin
https://gitlab.com/abologna/kubevirt-and-kvm/-/blob/master/Networking.md
# Networking
## Problem description
Service meshes (such as [Istio][], [Linkerd][]) typically expect
application processes to run on the same physical host, usually in a
separate user namespace. Network namespaces might be
https://gitlab.com/abologna/kubevirt-and-kvm/-/blob/master/Components.md
# Components
This document describes the various components of the KubeVirt
architecture, how they fit together, and how they compare to the
traditional virtualization architecture (QEMU + libvirt).
## Traditional architect
https://gitlab.com/abologna/kubevirt-and-kvm/-/blob/master/Live-Migration.md
# Live Migration
There are two scenarios where live migration is triggered in KubeVirt
* As per user request, by posting a `VirtualMachineInstanceMigration`
to the cluster
* As per cluster request, for instance on a N
https://gitlab.com/abologna/kubevirt-and-kvm/-/blob/master/CPU-Pinning.md
# CPU pinning
As is the case for many of KubeVirt's features, CPU pinning is
partially achieved using standard Kubernetes components: this both
reduces the amount of new code that has to be written and guarantees
better int
https://gitlab.com/abologna/kubevirt-and-kvm/-/blob/master/NUMA-Pinning.md
# NUMA pinning
KubeVirt doesn't currently implement NUMA pinning due to Kubernetes
limitation.
## Kubernetes Topology Manager
Allows aligning CPU and peripheral device allocations by NUMA node.
Many limitations:
* Not
https://gitlab.com/abologna/kubevirt-and-kvm/-/blob/master/Isolation.md
# Isolation
How is the QEMU process isolated from the host and from other VMs?
## Traditional virtualization
cgroups
* managed by libvirt
SELinux
* libvirt is privileged and QEMU is protected by SELinux policies set
by
https://gitlab.com/abologna/kubevirt-and-kvm/-/blob/master/Upgrades.md
# Upgrades
The KubeVirt installation and upgrade process are entirely controlled
by an [operator][], which is a common pattern in the Kubernetes
world. The operator is a piece of software running in the cluster and
managing th
https://gitlab.com/abologna/kubevirt-and-kvm/-/blob/master/Contacts.md
# Contacts and credits
# Contacts
The following people have agreed to serve as points of contact for
follow-up discussion around the topics included in these documents.
## Overall
* Andrea Bolognani <> (KVM user
https://gitlab.com/abologna/kubevirt-and-kvm/-/blob/master/Backpropagation.md
# Backpropagation
Whenever a partial VM configuration is submitted to libvirt, any missing
information is automatically filled in to obtain a configuration that's
complete enough to guarantee long-term guest ABI stabili
*fantastic* if we could keep the platform support policy
used by QEMU and libvirt as aligned as reasonably possible.
--
Andrea Bolognani / Red Hat / Virtualization
On Thu, 2020-09-17 at 17:35 +0100, Daniel P. Berrangé wrote:
> On Thu, Sep 17, 2020 at 06:07:00PM +0200, Andrea Bolognani wrote:
> > It would be *fantastic* if we could keep the platform support policy
> > used by QEMU and libvirt as aligned as reasonably possible.
>
> The cu
category is confusing, it seems out
> of the scope of the "better understanding and documenting the
> interactions between KubeVirt and KVM" and looks like left over
> notes.
That's probably because they absolutely are O:-)
> Maybe renaming the "Other topics&
ease comes out, just create a container
image for it and add it to the mix.
Additionally, the gitlab-runner Docker executor provides more
isolation than the shell executor, so running untrusted builds
becomes a more reasonable proposition - this is how the shared
runners on gitlab.com work - and you don't have to worry about your
jobs cleaning up properly after themselves nearly as much.
--
Andrea Bolognani / Red Hat / Virtualization
comments for vim.
Signed-off-by: Andrea Bolognani
---
docs/interop/firmware.json| 1 +
docs/interop/vhost-user.json | 1 +
qapi/authz.json | 1 +
qapi/block-core.json | 1 +
qapi/block.json | 1
59a290407a6f1cb3daba59069429d9665b
I'm not sure why gitlab-runner would use a fork rather than the
primary repository, but perhaps they can be convinced to switch and
gain better FreeBSD support in the process.
--
Andrea Bolognani / Red Hat / Virtualization
201 - 249 of 249 matches
Mail list logo
