[libvirt] libvirt default machine-type guarantees? (was Re: [Qemu-devel] [PATCH RFC] hw/pc: set q35 as the default x86 machine)
(CCing libvir-list) On Tue, Jun 05, 2018 at 09:43:00AM +0100, Daniel P. Berrangé wrote:
On Tue, Jun 05, 2018 at 09:27:46AM +0200, Gerd Hoffmann wrote:
Hi,
Add to that shortcuts like -cdrom stop working,
Maybe is fixable.
Already fixed for ages.
I see marking Q35 as the default machine a first step.
Maybe the better option is to go the arm route: Just don't define a default, so users have to specify pc or q35. That will make them notice there is a world beside 'pc', and we also avoid breaking things silently.
If QEMU removes the default, then libvirt will have to hardcode 'pc' as the default to maintain back compatibility, so I don't think that ends up as a net win
Is there an actual promise to never change the default machine-type documented in the libvirt API, or is this just fear of breaking existing code? -- Eduardo
On Tue, Jun 05, 2018 at 10:06:46AM -0300, Eduardo Habkost wrote:
(CCing libvir-list)
On Tue, Jun 05, 2018 at 09:43:00AM +0100, Daniel P. Berrangé wrote:
On Tue, Jun 05, 2018 at 09:27:46AM +0200, Gerd Hoffmann wrote:
Hi,
Add to that shortcuts like -cdrom stop working,
Maybe is fixable.
Already fixed for ages.
I see marking Q35 as the default machine a first step.
Maybe the better option is to go the arm route: Just don't define a default, so users have to specify pc or q35. That will make them notice there is a world beside 'pc', and we also avoid breaking things silently.
If QEMU removes the default, then libvirt will have to hardcode 'pc' as the default to maintain back compatibility, so I don't think that ends up as a net win
Is there an actual promise to never change the default machine-type documented in the libvirt API, or is this just fear of breaking existing code?
The risk of breaking things that currently work. Some of the things discussed here that risk breaking users if QEMU changes the default, have the same risk if libvirt changes the default. eg old OS versions that only work with PC, or more commonly pre-existing cloud disk images that were built against PC can't be assumed to just work against q35, even if the OS in the image supports it. If we want to get q35 broadly used for modern OS, then IMHO the best option is to record that metadata in libosinfo, as ew do for other virtual hardware preferences. That doesn't fix the problem of disk images that might not transparently boot between pc/q35, but at least avoids breaking OS that don't support q35 at all. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On Tue, Jun 05, 2018 at 02:12:32PM +0100, Daniel P. Berrangé wrote:
On Tue, Jun 05, 2018 at 10:06:46AM -0300, Eduardo Habkost wrote:
(CCing libvir-list)
On Tue, Jun 05, 2018 at 09:43:00AM +0100, Daniel P. Berrangé wrote:
On Tue, Jun 05, 2018 at 09:27:46AM +0200, Gerd Hoffmann wrote:
Hi,
Add to that shortcuts like -cdrom stop working,
Maybe is fixable.
Already fixed for ages.
I see marking Q35 as the default machine a first step.
Maybe the better option is to go the arm route: Just don't define a default, so users have to specify pc or q35. That will make them notice there is a world beside 'pc', and we also avoid breaking things silently.
If QEMU removes the default, then libvirt will have to hardcode 'pc' as the default to maintain back compatibility, so I don't think that ends up as a net win
Is there an actual promise to never change the default machine-type documented in the libvirt API, or is this just fear of breaking existing code?
The risk of breaking things that currently work. Some of the things discussed here that risk breaking users if QEMU changes the default, have the same risk if libvirt changes the default.
eg old OS versions that only work with PC, or more commonly pre-existing cloud disk images that were built against PC can't be assumed to just work against q35, even if the OS in the image supports it.
If we want to get q35 broadly used for modern OS, then IMHO the best option is to record that metadata in libosinfo, as ew do for other virtual hardware preferences. That doesn't fix the problem of disk images that might not transparently boot between pc/q35, but at least avoids breaking OS that don't support q35 at all.
This leads to a more general question: sometimes the defaults chosen by libvirt are obsolete or broken, and we might want to change them. Is there a process for changing defaults in libvirt, or libvirt is bound by past decisions forever? -- Eduardo
On Tue, Jun 05, 2018 at 10:35:38AM -0300, Eduardo Habkost wrote:
On Tue, Jun 05, 2018 at 02:12:32PM +0100, Daniel P. Berrangé wrote:
On Tue, Jun 05, 2018 at 10:06:46AM -0300, Eduardo Habkost wrote:
(CCing libvir-list)
On Tue, Jun 05, 2018 at 09:43:00AM +0100, Daniel P. Berrangé wrote:
On Tue, Jun 05, 2018 at 09:27:46AM +0200, Gerd Hoffmann wrote:
Hi,
> Add to that shortcuts like -cdrom > stop working,
Maybe is fixable.
Already fixed for ages.
I see marking Q35 as the default machine a first step.
Maybe the better option is to go the arm route: Just don't define a default, so users have to specify pc or q35. That will make them notice there is a world beside 'pc', and we also avoid breaking things silently.
If QEMU removes the default, then libvirt will have to hardcode 'pc' as the default to maintain back compatibility, so I don't think that ends up as a net win
Is there an actual promise to never change the default machine-type documented in the libvirt API, or is this just fear of breaking existing code?
The risk of breaking things that currently work. Some of the things discussed here that risk breaking users if QEMU changes the default, have the same risk if libvirt changes the default.
eg old OS versions that only work with PC, or more commonly pre-existing cloud disk images that were built against PC can't be assumed to just work against q35, even if the OS in the image supports it.
If we want to get q35 broadly used for modern OS, then IMHO the best option is to record that metadata in libosinfo, as ew do for other virtual hardware preferences. That doesn't fix the problem of disk images that might not transparently boot between pc/q35, but at least avoids breaking OS that don't support q35 at all.
This leads to a more general question: sometimes the defaults chosen by libvirt are obsolete or broken, and we might want to change them.
Is there a process for changing defaults in libvirt, or libvirt is bound by past decisions forever?
The general promise is that if you upgrade libvirt everything an application was doing before should still work in the same way. We also aim to promise that if you upgrade the hypervisor underneath things will still work. This is much harder to guarantee but we'll make reasonable effort to try to present an unchanged view to the mgmt app. Guest ABI is of course most critical part of that but anything that affects APIs a mgmt app is using relevant. This largely precludes changing defaults unless the feature goes away entirely or is unusable in some serious way. This is why we try to push the idea of policy decisions into a layer above with libosinfo suggesting defaults for individual guest OS. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On Tue, Jun 05, 2018 at 10:35:38AM -0300, Eduardo Habkost wrote:
On Tue, Jun 05, 2018 at 02:12:32PM +0100, Daniel P. Berrangé wrote:
On Tue, Jun 05, 2018 at 10:06:46AM -0300, Eduardo Habkost wrote:
(CCing libvir-list)
On Tue, Jun 05, 2018 at 09:43:00AM +0100, Daniel P. Berrangé wrote:
On Tue, Jun 05, 2018 at 09:27:46AM +0200, Gerd Hoffmann wrote:
Hi,
> Add to that shortcuts like -cdrom > stop working,
Maybe is fixable.
Already fixed for ages.
I see marking Q35 as the default machine a first step.
Maybe the better option is to go the arm route: Just don't define a default, so users have to specify pc or q35. That will make them notice there is a world beside 'pc', and we also avoid breaking things silently.
If QEMU removes the default, then libvirt will have to hardcode 'pc' as the default to maintain back compatibility, so I don't think that ends up as a net win
Is there an actual promise to never change the default machine-type documented in the libvirt API, or is this just fear of breaking existing code?
The risk of breaking things that currently work. Some of the things discussed here that risk breaking users if QEMU changes the default, have the same risk if libvirt changes the default.
eg old OS versions that only work with PC, or more commonly pre-existing cloud disk images that were built against PC can't be assumed to just work against q35, even if the OS in the image supports it.
If we want to get q35 broadly used for modern OS, then IMHO the best option is to record that metadata in libosinfo, as ew do for other virtual hardware preferences. That doesn't fix the problem of disk images that might not transparently boot between pc/q35, but at least avoids breaking OS that don't support q35 at all.
This leads to a more general question: sometimes the defaults chosen by libvirt are obsolete or broken, and we might want to change them.
Is there a process for changing defaults in libvirt, or libvirt is bound by past decisions forever?
If the default was always recorded in the domain XML it is safe to change it because it will not affect already existing domains or migration but if the default is not recorded in the domain XML there needs to be a lot of compatibility code. In the past we've changed some of the defaults, for example default device model. Pavel
On Tue, Jun 05, 2018 at 03:44:39PM +0200, Pavel Hrdina wrote:
On Tue, Jun 05, 2018 at 10:35:38AM -0300, Eduardo Habkost wrote:
On Tue, Jun 05, 2018 at 02:12:32PM +0100, Daniel P. Berrangé wrote:
On Tue, Jun 05, 2018 at 10:06:46AM -0300, Eduardo Habkost wrote:
(CCing libvir-list)
On Tue, Jun 05, 2018 at 09:43:00AM +0100, Daniel P. Berrangé wrote:
On Tue, Jun 05, 2018 at 09:27:46AM +0200, Gerd Hoffmann wrote:
Hi,
> > Add to that shortcuts like -cdrom > > stop working, > > Maybe is fixable.
Already fixed for ages.
> I see marking Q35 as the default machine a first step.
Maybe the better option is to go the arm route: Just don't define a default, so users have to specify pc or q35. That will make them notice there is a world beside 'pc', and we also avoid breaking things silently.
If QEMU removes the default, then libvirt will have to hardcode 'pc' as the default to maintain back compatibility, so I don't think that ends up as a net win
Is there an actual promise to never change the default machine-type documented in the libvirt API, or is this just fear of breaking existing code?
The risk of breaking things that currently work. Some of the things discussed here that risk breaking users if QEMU changes the default, have the same risk if libvirt changes the default.
eg old OS versions that only work with PC, or more commonly pre-existing cloud disk images that were built against PC can't be assumed to just work against q35, even if the OS in the image supports it.
If we want to get q35 broadly used for modern OS, then IMHO the best option is to record that metadata in libosinfo, as ew do for other virtual hardware preferences. That doesn't fix the problem of disk images that might not transparently boot between pc/q35, but at least avoids breaking OS that don't support q35 at all.
This leads to a more general question: sometimes the defaults chosen by libvirt are obsolete or broken, and we might want to change them.
Is there a process for changing defaults in libvirt, or libvirt is bound by past decisions forever?
If the default was always recorded in the domain XML it is safe to change it because it will not affect already existing domains or migration but if the default is not recorded in the domain XML there needs to be a lot of compatibility code.
That's the opposite of what Daniel said above, isn't it? The machine-type is always recorded in the domain XML, but it's still considered unsafe to change. -- Eduardo
On Tue, Jun 05, 2018 at 11:03:46AM -0300, Eduardo Habkost wrote:
On Tue, Jun 05, 2018 at 03:44:39PM +0200, Pavel Hrdina wrote:
On Tue, Jun 05, 2018 at 10:35:38AM -0300, Eduardo Habkost wrote:
On Tue, Jun 05, 2018 at 02:12:32PM +0100, Daniel P. Berrangé wrote:
On Tue, Jun 05, 2018 at 10:06:46AM -0300, Eduardo Habkost wrote:
(CCing libvir-list)
On Tue, Jun 05, 2018 at 09:43:00AM +0100, Daniel P. Berrangé wrote:
On Tue, Jun 05, 2018 at 09:27:46AM +0200, Gerd Hoffmann wrote: > Hi, > > > > Add to that shortcuts like -cdrom > > > stop working, > > > > Maybe is fixable. > > Already fixed for ages. > > > I see marking Q35 as the default machine a first step. > > Maybe the better option is to go the arm route: Just don't define a > default, so users have to specify pc or q35. That will make them notice > there is a world beside 'pc', and we also avoid breaking things > silently.
If QEMU removes the default, then libvirt will have to hardcode 'pc' as the default to maintain back compatibility, so I don't think that ends up as a net win
Is there an actual promise to never change the default machine-type documented in the libvirt API, or is this just fear of breaking existing code?
The risk of breaking things that currently work. Some of the things discussed here that risk breaking users if QEMU changes the default, have the same risk if libvirt changes the default.
eg old OS versions that only work with PC, or more commonly pre-existing cloud disk images that were built against PC can't be assumed to just work against q35, even if the OS in the image supports it.
If we want to get q35 broadly used for modern OS, then IMHO the best option is to record that metadata in libosinfo, as ew do for other virtual hardware preferences. That doesn't fix the problem of disk images that might not transparently boot between pc/q35, but at least avoids breaking OS that don't support q35 at all.
This leads to a more general question: sometimes the defaults chosen by libvirt are obsolete or broken, and we might want to change them.
Is there a process for changing defaults in libvirt, or libvirt is bound by past decisions forever?
If the default was always recorded in the domain XML it is safe to change it because it will not affect already existing domains or migration but if the default is not recorded in the domain XML there needs to be a lot of compatibility code.
That's the opposite of what Daniel said above, isn't it? The machine-type is always recorded in the domain XML, but it's still considered unsafe to change.
Yes, I disagree with that Pavel has written here. The domain XML recording of settings is critical for preserving guest ABI for migration, etc, so obviously must be stable. Even if there is *no* domain XML yet, however, libvirt still aims to avoid changes in defaults that are liable to break an existing mgmt application creating guests in future. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On Tue, Jun 05, 2018 at 03:07:04PM +0100, Daniel P. Berrangé wrote:
On Tue, Jun 05, 2018 at 11:03:46AM -0300, Eduardo Habkost wrote:
On Tue, Jun 05, 2018 at 03:44:39PM +0200, Pavel Hrdina wrote:
On Tue, Jun 05, 2018 at 10:35:38AM -0300, Eduardo Habkost wrote:
On Tue, Jun 05, 2018 at 02:12:32PM +0100, Daniel P. Berrangé wrote:
On Tue, Jun 05, 2018 at 10:06:46AM -0300, Eduardo Habkost wrote:
(CCing libvir-list)
On Tue, Jun 05, 2018 at 09:43:00AM +0100, Daniel P. Berrangé wrote: > On Tue, Jun 05, 2018 at 09:27:46AM +0200, Gerd Hoffmann wrote: > > Hi, > > > > > > Add to that shortcuts like -cdrom > > > > stop working, > > > > > > Maybe is fixable. > > > > Already fixed for ages. > > > > > I see marking Q35 as the default machine a first step. > > > > Maybe the better option is to go the arm route: Just don't define a > > default, so users have to specify pc or q35. That will make them notice > > there is a world beside 'pc', and we also avoid breaking things > > silently. > > If QEMU removes the default, then libvirt will have to hardcode > 'pc' as the default to maintain back compatibility, so I don't > think that ends up as a net win
Is there an actual promise to never change the default machine-type documented in the libvirt API, or is this just fear of breaking existing code?
The risk of breaking things that currently work. Some of the things discussed here that risk breaking users if QEMU changes the default, have the same risk if libvirt changes the default.
eg old OS versions that only work with PC, or more commonly pre-existing cloud disk images that were built against PC can't be assumed to just work against q35, even if the OS in the image supports it.
If we want to get q35 broadly used for modern OS, then IMHO the best option is to record that metadata in libosinfo, as ew do for other virtual hardware preferences. That doesn't fix the problem of disk images that might not transparently boot between pc/q35, but at least avoids breaking OS that don't support q35 at all.
This leads to a more general question: sometimes the defaults chosen by libvirt are obsolete or broken, and we might want to change them.
Is there a process for changing defaults in libvirt, or libvirt is bound by past decisions forever?
If the default was always recorded in the domain XML it is safe to change it because it will not affect already existing domains or migration but if the default is not recorded in the domain XML there needs to be a lot of compatibility code.
That's the opposite of what Daniel said above, isn't it? The machine-type is always recorded in the domain XML, but it's still considered unsafe to change.
Yes, I disagree with that Pavel has written here. The domain XML recording of settings is critical for preserving guest ABI for migration, etc, so obviously must be stable. Even if there is *no* domain XML yet, however, libvirt still aims to avoid changes in defaults that are liable to break an existing mgmt application creating guests in future.
Yes in general we try to avoid changing defaults and no it's possible to do it if there is good reason <568887a32f9985b95d998dd0d675255ea985013f>. So technically there is a way but usually it's not good idea. I should have noted in the first reply that machine type is huge change and that my statement applies to smaller changes. Pavel
On Tue, Jun 05, 2018 at 11:03:46AM -0300, Eduardo Habkost wrote:
On Tue, Jun 05, 2018 at 03:44:39PM +0200, Pavel Hrdina wrote:
On Tue, Jun 05, 2018 at 10:35:38AM -0300, Eduardo Habkost wrote:
On Tue, Jun 05, 2018 at 02:12:32PM +0100, Daniel P. Berrangé wrote:
On Tue, Jun 05, 2018 at 10:06:46AM -0300, Eduardo Habkost wrote:
(CCing libvir-list)
On Tue, Jun 05, 2018 at 09:43:00AM +0100, Daniel P. Berrangé wrote:
On Tue, Jun 05, 2018 at 09:27:46AM +0200, Gerd Hoffmann wrote: > Hi, > > > > Add to that shortcuts like -cdrom > > > stop working, > > > > Maybe is fixable. > > Already fixed for ages. > > > I see marking Q35 as the default machine a first step. > > Maybe the better option is to go the arm route: Just don't define a > default, so users have to specify pc or q35. That will make them notice > there is a world beside 'pc', and we also avoid breaking things > silently.
If QEMU removes the default, then libvirt will have to hardcode 'pc' as the default to maintain back compatibility, so I don't think that ends up as a net win
Is there an actual promise to never change the default machine-type documented in the libvirt API, or is this just fear of breaking existing code?
The risk of breaking things that currently work. Some of the things discussed here that risk breaking users if QEMU changes the default, have the same risk if libvirt changes the default.
eg old OS versions that only work with PC, or more commonly pre-existing cloud disk images that were built against PC can't be assumed to just work against q35, even if the OS in the image supports it.
If we want to get q35 broadly used for modern OS, then IMHO the best option is to record that metadata in libosinfo, as ew do for other virtual hardware preferences. That doesn't fix the problem of disk images that might not transparently boot between pc/q35, but at least avoids breaking OS that don't support q35 at all.
This leads to a more general question: sometimes the defaults chosen by libvirt are obsolete or broken, and we might want to change them.
Is there a process for changing defaults in libvirt, or libvirt is bound by past decisions forever?
If the default was always recorded in the domain XML it is safe to change it because it will not affect already existing domains or migration but if the default is not recorded in the domain XML there needs to be a lot of compatibility code.
That's the opposite of what Daniel said above, isn't it? The machine-type is always recorded in the domain XML, but it's still considered unsafe to change.
It's not opposite. The thing is that some of the defaults are not that easy change for other reasons, not from libvirt POV or because of ABI stability. In general yes, it is possible to change it but in some cases it might not be good idea, one example could be the machine time. Changing default machine time affects the whole guest and may break a lot of use-cases but changing some default device model if the current default is obsolete and most of the OSes supports the new one should be safe. Pavel
On Tue, Jun 05, 2018 at 02:12:32PM +0100, Daniel P. Berrangé wrote:
eg old OS versions that only work with PC, or more commonly pre-existing cloud disk images that were built against PC can't be assumed to just work against q35, even if the OS in the image supports it.
I don't understand that part - when using libvirt domain xml records the machine type used for the install, so it seems that installed images won't be affected. -- MST
On Tue, Jun 05, 2018 at 07:16:56PM +0300, Michael S. Tsirkin wrote:
On Tue, Jun 05, 2018 at 02:12:32PM +0100, Daniel P. Berrangé wrote:
eg old OS versions that only work with PC, or more commonly pre-existing cloud disk images that were built against PC can't be assumed to just work against q35, even if the OS in the image supports it.
I don't understand that part - when using libvirt domain xml records the machine type used for the install, so it seems that installed images won't be affected.
There's no libvirt XML for distributed cloud images, it is created whenever the image is instantiated. Libvirt also doesn't require use of its persistent guest feature - it is possible to create so called "transient" guests with libvirt where you just provide an XML doc at each boot up, and libvirt does not save this XML between boots. Even if an app is using persistent libvirt XML they might not boot the VM on the same host each time, so the previous persistent XML may not be available at next boot up. So there's many ways existing deployed guests can be affected by changes in defaults, even when libvirt records info in the XML. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
participants (4)
-
Daniel P. Berrangé -
Eduardo Habkost -
Michael S. Tsirkin -
Pavel Hrdina