Peter Xu writes:
> On Thu, Jul 11, 2024 at 11:44:08AM -0300, Fabiano Rosas wrote:
>> But of course, that means we cannot claim to support all kinds of
>> forward migrations anymore. Only those in the 6 year period.
>
> That "6 years" comes from machine type deprecation period, and migration
> com
On Thu, Jul 11, 2024 at 11:44:08AM -0300, Fabiano Rosas wrote:
> But of course, that means we cannot claim to support all kinds of
> forward migrations anymore. Only those in the 6 year period.
That "6 years" comes from machine type deprecation period, and migration
compatibility is mostly only at
Peter Xu writes:
> On Thu, Jul 11, 2024 at 10:34:12AM -0300, Fabiano Rosas wrote:
>> Is there an easy way to look at a field and tell in which machine type's
>> timeframe it was introduced?
>
> I am not aware of any.
>
>> If the machine type of that era has been removed, then the field is free
>>
On Thu, Jul 11, 2024 at 10:34:12AM -0300, Fabiano Rosas wrote:
> Is there an easy way to look at a field and tell in which machine type's
> timeframe it was introduced?
I am not aware of any.
> If the machine type of that era has been removed, then the field is free
> to go as well. I'd prefer if
Peter Xu writes:
> On Wed, Jul 10, 2024 at 06:38:26PM -0300, Fabiano Rosas wrote:
>> Peter Xu writes:
>>
>> > On Wed, Jul 10, 2024 at 04:48:23PM -0300, Fabiano Rosas wrote:
>> >> Peter Xu writes:
>> >>
>> >> > On Wed, Jul 10, 2024 at 01:21:51PM -0300, Fabiano Rosas wrote:
>> >> >> It's not ab
On Tue, Jul 09, 2024 at 08:41:17AM GMT, mirlos--- via Devel wrote:
> My reply by email has not arrived by now, hence I'll post it via
> the archive site. Sorry for the potential double post.
No double post as far as I can tell :)
> Older bootloaders were not split into separate _CODE.fd and _VARS
On Thu, Jul 11, 2024 at 14:55:17 +0200, Jiri Denemark wrote:
> Recent commit v10.4.0-87-gd9935a5c4f made a reasonable change to only
> reset beingDestroyed back to false when vm->def->id is reset to make
> sure other code can detect a domain is (about to become) inactive. It
> even added a comment
Recent commit v10.4.0-87-gd9935a5c4f made a reasonable change to only
reset beingDestroyed back to false when vm->def->id is reset to make
sure other code can detect a domain is (about to become) inactive. It
even added a comment saying any caller of qemuProcessBeginStopJob is
supposed to call qemu
On a Thursday in 2024, Michal Privoznik wrote:
It all started with me looking at the --help output which also
printed "bhyve" as supported hypervisor type.
It did not say it is a supported hypervisor type, it merely listed it as
a supported option. I don't think we need this patch.
It works as
On a Thursday in 2024, Michal Privoznik wrote:
If virt-host-validate is ran on a SEV-SNP capable machine, an
extra "PASS" is printed out. This is because
virHostValidateAMDSev() prints "PASS" and then returns 1
(indicating success) which in turn makes the caller
(virHostValidateSecureGuests()) pr
It all started with me looking at the --help output which also
printed "bhyve" as supported hypervisor type. Well, it's not on
my Linux machine. To resolve this, I'm just creating a static
array of { "$driver", callback() } pairs and iterating over it.
The array is then initialized at compile time
If virt-host-validate is ran on a SEV-SNP capable machine, an
extra "PASS" is printed out. This is because
virHostValidateAMDSev() prints "PASS" and then returns 1
(indicating success) which in turn makes the caller
(virHostValidateSecureGuests()) print "PASS" again. Just drop the
extra printing in
12 matches
Mail list logo
