On Mon, Sep 13, 2021 at 4:10 PM Peter Krempa wrote:
> On Fri, Sep 10, 2021 at 22:04:01 +0300, Nir Soffer wrote:
> > On Fri, Sep 10, 2021 at 4:35 PM Peter Krempa wrote:
> > >
> > > We don't support all startup policies with all source types so to
> > > correctly allow switching from a 'file'
Added the following new libvirt conf option to the release note to indicate
their availability with the next release:
Signed-off-by: Ani Sinha
---
NEWS.rst | 7 +++
1 file changed, 7 insertions(+)
diff --git a/NEWS.rst b/NEWS.rst
index fd20e50d18..0bf4ee002c 100644
---
qemu added support for i440fx specific global boolean flag
PIIX4_PM.acpi-pci-hotplug-with-bridge-support
around version 2.1. This flag is enabled by default. When disabled, it turns
off acpi pci hotplug for cold plugged pci bridges in i440fx machine types.
Very recently, in qemu version 6.1,
This change adds backend qemu command line support for new libvirt global
feature 'acpi-bridge-hotplug'. This option can be used as following:
The '' sub-element under '' is also newly introduced.
'acpi-bridge-hotplug' turns on the following command line option to qemu for
x86
This change introduces a new libvirt sub-element under that
can be used to configure all pci related features.
Currently the only sub-sub element supported by this sub-element is
'acpi-bridge-hotplug' as shown below:
The above option is only available for qemu driver and that too
changelog:
v4: split the original series into two - pci-root controller specific one
(https://www.mail-archive.com/libvir-list@redhat.com/msg221645.html)
and this one specific to pci bridges.
The conf xml has been introduced as per suggestion by Berrange here:
On Tue, Sep 28, 2021 at 10:43 AM Jie Wang wrote:
> block type CDROM also support startupPolicy in the past, so
>
s/block/Block/
"in the past" could be more detailed. It's better if you tell from which
version to which version the
startupPolicy of block type cdrom is supported
> let us fix it.
> -Original Message-
> From: Daniel P. Berrangé
> Sent: Tuesday, September 28, 2021 10:15 PM
> To: Huang, Haibin
> Cc: libvir-list@redhat.com; Ding, Jian-feng ; Yang,
> Lin A ; Lu, Lianhao ;
> pbonz...@redhat.com; pkre...@redhat.com; twied...@redhat.com;
> phrd...@redhat.com;
On Wed, Sep 29, 2021 at 7:58 PM Igor Mammedov wrote:
>
> On Tue, 28 Sep 2021 11:47:26 +0100
> Daniel P. Berrangé wrote:
>
> > On Tue, Sep 28, 2021 at 03:28:04PM +0530, Ani Sinha wrote:
> > >
> > >
> > > On Tue, 28 Sep 2021, Daniel P. Berrangé wrote:
> > >
> > > > On Tue, Sep 28, 2021 at
On Tue, 28 Sep 2021 11:47:26 +0100
Daniel P. Berrangé wrote:
> On Tue, Sep 28, 2021 at 03:28:04PM +0530, Ani Sinha wrote:
> >
> >
> > On Tue, 28 Sep 2021, Daniel P. Berrangé wrote:
> >
> > > On Tue, Sep 28, 2021 at 02:35:47PM +0530, Ani Sinha wrote:
> > > >
> > > >
> > > > On Tue, 28 Sep
On Wed, Sep 29, 2021 at 02:49:32PM +0200, Igor Mammedov wrote:
> On Tue, 28 Sep 2021 11:59:42 +0100
> Daniel P. Berrangé wrote:
>
> > On Tue, Sep 28, 2021 at 11:47:26AM +0100, Daniel P. Berrangé wrote:
> > > On Tue, Sep 28, 2021 at 03:28:04PM +0530, Ani Sinha wrote:
> > > >
> > > >
> > > >
On Tue, 28 Sep 2021 11:59:42 +0100
Daniel P. Berrangé wrote:
> On Tue, Sep 28, 2021 at 11:47:26AM +0100, Daniel P. Berrangé wrote:
> > On Tue, Sep 28, 2021 at 03:28:04PM +0530, Ani Sinha wrote:
> > >
> > >
> > > On Tue, 28 Sep 2021, Daniel P. Berrangé wrote:
> > >
> > > > On Tue, Sep 28,
I have just tagged v7.8.0-rc2 in the repository and pushed signed
tarballs and source RPMs to https://libvirt.org/sources/
Please give the release candidate some testing and in case you find a
serious issue which should have a fix in the upcoming release, feel
free to reply to this thread to make
On Wed, Sep 29, 2021 at 11:10:35AM +0100, Daniel P. Berrangé wrote:
> On Wed, Sep 29, 2021 at 10:57:19AM +0100, Richard W.M. Jones wrote:
> > Looking at the qemu code the problem IMHO is:
> >
> >
On Wed, Sep 29, 2021 at 10:46:38AM +0100, Richard W.M. Jones wrote:
> I don't know why we decided to use a GUID for this. The feature
> itself (https://go.microsoft.com/fwlink/?LinkId=260709) defines it as
> an 128 bit / 8 byte number. The only connection to GUIDs is the size.
*cough* .. 16
On Wed, Sep 29, 2021 at 11:07:30AM +0100, Daniel P. Berrangé wrote:
> I'm not sure if we actually need the full driver or not for testing
> purposes. The the GenID is just in memory somewhere, and the somewhere
> is reported via ACPI table entry. For QEMU its easy as the data is
> exposed via
On Wed, Sep 29, 2021 at 10:57:19AM +0100, Richard W.M. Jones wrote:
> Looking at the qemu code the problem IMHO is:
>
> https://gitlab.com/qemu-project/qemu/-/blob/6b54a31bf7b403672a798b6443b1930ae6c74dea/docs/specs/vmgenid.txt#L189
>
On Wed, Sep 29, 2021 at 10:46:39AM +0100, Richard W.M. Jones wrote:
> On Wed, Sep 29, 2021 at 10:33:43AM +0100, Daniel P. Berrangé wrote:
> > Ultimately as long as the mapping from libvirt XML to guest visible
> > string is consistent across drivers, that's sufficient.
> >
> > > Adding qemu-devel
Looking at the qemu code the problem IMHO is:
https://gitlab.com/qemu-project/qemu/-/blob/6b54a31bf7b403672a798b6443b1930ae6c74dea/docs/specs/vmgenid.txt#L189
https://gitlab.com/qemu-project/qemu/-/blob/6b54a31bf7b403672a798b6443b1930ae6c74dea/hw/acpi/vmgenid.c#L37
This byte swapping makes no
On Wed, Sep 29, 2021 at 10:33:43AM +0100, Daniel P. Berrangé wrote:
> On Wed, Sep 29, 2021 at 10:20:44AM +0100, Richard W.M. Jones wrote:
> > On Wed, Sep 29, 2021 at 10:01:55AM +0200, Michal Privoznik wrote:
> > > Apparently, parsing vmx.genid is not as easy as I thought. Anyway, it
> > > was
On Wed, Sep 29, 2021 at 10:20:44AM +0100, Richard W.M. Jones wrote:
> On Wed, Sep 29, 2021 at 10:01:55AM +0200, Michal Privoznik wrote:
> > Apparently, parsing vmx.genid is not as easy as I thought. Anyway, it
> > was brought up in a private thread that libvirt doesn't report correct
> > UUIDs.
On Wed, Sep 29, 2021 at 10:01:55AM +0200, Michal Privoznik wrote:
> Apparently, parsing vmx.genid is not as easy as I thought. Anyway, it
> was brought up in a private thread that libvirt doesn't report correct
> UUIDs. For instance for the following input:
>
> vm.genid = "-8536691797830587195"
Not a long ago I've introduced parsing of vmx.genid and
vmx.genidX properties. They map onto our element. The
implementation was quite straightforward: the UUID which is 128
bits long is split into two equally long parts which I then put
next to each other and used virUUIDParse() to fill the UUID
Apparently, parsing vmx.genid is not as easy as I thought. Anyway, it
was brought up in a private thread that libvirt doesn't report correct
UUIDs. For instance for the following input:
vm.genid = "-8536691797830587195"
vm.genidX = "-1723453263670062919"
Libvirt would report:
On Tue, 28 Sep 2021, Daniel P. Berrangé wrote:
> On Tue, Sep 28, 2021 at 06:14:12PM +0530, Ani Sinha wrote:
> > On Tue, Sep 28, 2021 at 17:49 Daniel P. Berrangé
> > wrote:
> >
> > > On Tue, Sep 28, 2021 at 05:31:43PM +0530, Ani Sinha wrote:
> > > >
> > > >
> > > > On Tue, 28 Sep 2021, Daniel
25 matches
Mail list logo
