Upgrading the host
Hello-- I'm planning on upgrading the OS on my host machine by doing manual re-installation, which will trigger an upgrade of libvirt from 1.1.3 to 6.1.0. Hardware, storage volumes & paths, etc., will be the same after upgrade. I was going to redefine & start everything from .xml files, starting with the network virsh net-define <network XML> virsh net-autostart <network> virsh net-start <network> and following with all the guests virsh define <domain XML> virsh autostart <domain> virsh start <domain> I have the following questions: 1. Do I need to generate XML dumps manually, or is it ok to use the ones from host's /etc/libvirt? 2. Do I need to define & start storage pools & volumes explicitly, or will they be picked up from domain definitions? 3. Anything else I should worry about or prepare ahead? --Marcin
On 2/12/21 2:10 AM, Marcin Struzak wrote:
Hello--
I'm planning on upgrading the OS on my host machine by doing manual re-installation, which will trigger an upgrade of libvirt from 1.1.3 to 6.1.0. Hardware, storage volumes & paths, etc., will be the same after upgrade.
I was going to redefine & start everything from .xml files, starting with the network
virsh net-define <network XML> virsh net-autostart <network> virsh net-start <network>
and following with all the guests
virsh define <domain XML> virsh autostart <domain> virsh start <domain>
If you are just upgrading the libvirt package then you do not need to do any of this. Libvirt picks everything up after it's restarted. But if you are installing host from scratch then ..
I have the following questions:
1. Do I need to generate XML dumps manually, or is it ok to use the ones from host's /etc/libvirt?
.. yes, back up XMls here and use define & start as you suggested.
2. Do I need to define & start storage pools & volumes explicitly, or will they be picked up from domain definitions?
Storage pools won't be defined automatically. You need to save their XMLs too. You can find them under /etc/libvirt/storage/. Don't forget on secrets if you use them too.
3. Anything else I should worry about or prepare ahead?
Not strictly related to libvirt, but machine types might be problem. I guess qemu will be upgraded too and in general the machine type you're using for a domain might not be available in upgraded qemu. You can view supported machine types by running 'virsh capabilities' with upgraded qemu. Good luck! Michal
On Tue, Feb 16, 2021 at 09:51:52AM +0100, Michal Privoznik wrote:
On 2/12/21 2:10 AM, Marcin Struzak wrote:
Hello--
I'm planning on upgrading the OS on my host machine by doing manual re-installation, which will trigger an upgrade of libvirt from 1.1.3 to 6.1.0. Hardware, storage volumes & paths, etc., will be the same after upgrade.
I was going to redefine & start everything from .xml files, starting with the network
virsh net-define <network XML> virsh net-autostart <network> virsh net-start <network>
and following with all the guests
virsh define <domain XML> virsh autostart <domain> virsh start <domain>
If you are just upgrading the libvirt package then you do not need to do any of this. Libvirt picks everything up after it's restarted. But if you are installing host from scratch then ..
I have the following questions:
1. Do I need to generate XML dumps manually, or is it ok to use the ones from host's /etc/libvirt?
.. yes, back up XMls here and use define & start as you suggested.
2. Do I need to define & start storage pools & volumes explicitly, or will they be picked up from domain definitions?
Storage pools won't be defined automatically. You need to save their XMLs too. You can find them under /etc/libvirt/storage/. Don't forget on secrets if you use them too.
Needless to say, if you're backing up /etc/libvirt/<whatever> make sure libvirtd is down first, so that all the settings are properly dumped by the daemon to the respective XMLs. Erik
On 2/16/2021 1:02 AM, Erik Skultety wrote:
[...] Needless to say, if you're backing up /etc/libvirt/<whatever> make sure libvirtd is down first, so that all the settings are properly dumped by the daemon to the respective XMLs.
Erik
Absolutely! Not concerned about downtime here, just that after the upgrade everything comes back up like before. Speaking of settings dumped into XMLs, why are the files in /etc/libvirt/qemu ever so slightly different from a manual dump using virsh dumpxml & friends? E.g., for a domain I have a section <resource> <partition>/machine</partition> </resource> <alias ... /> entries for all devices, a tty attribute & <source ... /> for console, etc., in the manual dump only? --Marcin
On 2/17/21 2:59 AM, Marcin Struzak wrote:
On 2/16/2021 1:02 AM, Erik Skultety wrote:
[...] Needless to say, if you're backing up /etc/libvirt/<whatever> make sure libvirtd is down first, so that all the settings are properly dumped by the daemon to the respective XMLs.
I'm not convinced this is the case - we go great lengths to make sure XMLs are saved onto disk safely and as soon as possible. Not only because users might kill libvirtd, it may also crash. But doesn't hurt to shut the daemon off.
Erik
Absolutely! Not concerned about downtime here, just that after the upgrade everything comes back up like before.
Speaking of settings dumped into XMLs, why are the files in /etc/libvirt/qemu ever so slightly different from a manual dump using virsh dumpxml & friends? E.g., for a domain I have a section
<resource> <partition>/machine</partition> </resource>
<alias ... /> entries for all devices, a tty attribute & <source ... /> for console, etc., in the manual dump only?
Because 'virsh dumpxml' prints so called live XML if guest is running; or inactive XML if guest is not running. If the guest is running but you want to print the inactive XML you can do 'virsh dumpxml --inactive'. The difference between live and inactive XML is that the former contains runtime information (like CGroup placement, device aliases generated when guest is created, domain ID, etc.). If you dump inactive XML then the output should be the same as under /etc/libvirt. Michal
On 2/17/21 3:11 AM, Michal Privoznik wrote:
On 2/17/21 2:59 AM, Marcin Struzak wrote:
On 2/16/2021 1:02 AM, Erik Skultety wrote:
[...] Needless to say, if you're backing up /etc/libvirt/<whatever> make sure libvirtd is down first, so that all the settings are properly dumped by the daemon to the respective XMLs.
I'm not convinced this is the case - we go great lengths to make sure XMLs are saved onto disk safely and as soon as possible. Not only because users might kill libvirtd, it may also crash.
But doesn't hurt to shut the daemon off.
Erik
Absolutely! Not concerned about downtime here, just that after the upgrade everything comes back up like before.
Speaking of settings dumped into XMLs, why are the files in /etc/libvirt/qemu ever so slightly different from a manual dump using virsh dumpxml & friends? E.g., for a domain I have a section
<resource> <partition>/machine</partition> </resource>
<alias ... /> entries for all devices, a tty attribute & <source ... /> for console, etc., in the manual dump only?
Because 'virsh dumpxml' prints so called live XML if guest is running; or inactive XML if guest is not running. If the guest is running but you want to print the inactive XML you can do 'virsh dumpxml --inactive'.
And by the way, if you're dumping the xml in order to redefine it later, you really should us "--inactive" because otherwise the result will be more than "slightly" different. In particular, if you have certain types of networks that are pools of hostdev or macvtap devices, the <interface> elements for those will be <interface type='hostdev|direct'> in the status output rather than the <interface type='network'> that you would need to properly re-define the domain.
The difference between live and inactive XML is that the former contains runtime information (like CGroup placement, device aliases generated when guest is created, domain ID, etc.). If you dump inactive XML then the output should be the same as under /etc/libvirt.
Michal
On 2/12/21 2:10 AM, Marcin Struzak wrote: [...]
3. Anything else I should worry about or prepare ahead?
Not strictly related to libvirt, but machine types might be problem. I guess qemu will be upgraded too and in general the machine type you're using for a domain might not be available in upgraded qemu. Correct, it looks like qemu will go from 1.6.2 to 4.2.1...
You can view supported machine types by running 'virsh capabilities' with upgraded qemu. machine is pc-i440fx-1.6 in all my domains. Is there a simple way to
On 2/16/2021 12:51 AM, Michal Privoznik wrote: figure out if that's supported in libvirt 6.1.0 (without installing it)?
Good luck!
Michal
Thank you for a quick & detailed answer. --Marcin
On 2/17/21 2:45 AM, Marcin Struzak wrote:
On 2/12/21 2:10 AM, Marcin Struzak wrote: [...]
3. Anything else I should worry about or prepare ahead?
Not strictly related to libvirt, but machine types might be problem. I guess qemu will be upgraded too and in general the machine type you're using for a domain might not be available in upgraded qemu. Correct, it looks like qemu will go from 1.6.2 to 4.2.1...
You can view supported machine types by running 'virsh capabilities' with upgraded qemu. machine is pc-i440fx-1.6 in all my domains. Is there a simple way to
On 2/16/2021 12:51 AM, Michal Privoznik wrote: figure out if that's supported in libvirt 6.1.0 (without installing it)?
It's not libvirt who has say in machine types. Libvirt treats machine type as an opaque string. But I can see that pc-i440fx-1.6 is still available even with the latest QEMU release: # /usr/bin/qemu-system-x86_64 -version QEMU emulator version 5.2.0 # virsh capabilities | grep pc-i440fx-1.6 <machine maxCpus='255'>pc-i440fx-1.6</machine> <machine maxCpus='255'>pc-i440fx-1.6</machine> So you are safe on that front. Michal
On 2/17/2021 12:23 AM, Michal Privoznik wrote:
On 2/17/21 2:45 AM, Marcin Struzak wrote:
On 2/12/21 2:10 AM, Marcin Struzak wrote: [...]
3. Anything else I should worry about or prepare ahead?
Not strictly related to libvirt, but machine types might be problem. I guess qemu will be upgraded too and in general the machine type you're using for a domain might not be available in upgraded qemu. Correct, it looks like qemu will go from 1.6.2 to 4.2.1...
You can view supported machine types by running 'virsh capabilities' with upgraded qemu. machine is pc-i440fx-1.6 in all my domains. Is there a simple way to
On 2/16/2021 12:51 AM, Michal Privoznik wrote: figure out if that's supported in libvirt 6.1.0 (without installing it)?
It's not libvirt who has say in machine types. Libvirt treats machine type as an opaque string. But I can see that pc-i440fx-1.6 is still available even with the latest QEMU release:
# /usr/bin/qemu-system-x86_64 -version QEMU emulator version 5.2.0
# virsh capabilities | grep pc-i440fx-1.6 <machine maxCpus='255'>pc-i440fx-1.6</machine> <machine maxCpus='255'>pc-i440fx-1.6</machine>
So you are safe on that front.
Excellent, thank you for checking. Out of curiosity: what would have been my course of action if that particular machine were no longer defined? I assume: substitute with a close match (after figuring out how do determine what counts as "close") & hope that the VMs (all Fedoras & Ubuntus) cope & adjust? --Marcin
On Wed, Feb 17, 2021 at 07:15:03 -0800, Marcin Struzak wrote:
On 2/17/2021 12:23 AM, Michal Privoznik wrote:
On 2/17/21 2:45 AM, Marcin Struzak wrote:
On 2/12/21 2:10 AM, Marcin Struzak wrote: [...]
3. Anything else I should worry about or prepare ahead?
Not strictly related to libvirt, but machine types might be problem. I guess qemu will be upgraded too and in general the machine type you're using for a domain might not be available in upgraded qemu. Correct, it looks like qemu will go from 1.6.2 to 4.2.1...
You can view supported machine types by running 'virsh capabilities' with upgraded qemu. machine is pc-i440fx-1.6 in all my domains. Is there a simple way to
On 2/16/2021 12:51 AM, Michal Privoznik wrote: figure out if that's supported in libvirt 6.1.0 (without installing it)?
It's not libvirt who has say in machine types. Libvirt treats machine type as an opaque string. But I can see that pc-i440fx-1.6 is still available even with the latest QEMU release:
# /usr/bin/qemu-system-x86_64 -version QEMU emulator version 5.2.0
# virsh capabilities | grep pc-i440fx-1.6 <machine maxCpus='255'>pc-i440fx-1.6</machine> <machine maxCpus='255'>pc-i440fx-1.6</machine>
So you are safe on that front.
Excellent, thank you for checking.
Out of curiosity: what would have been my course of action if that particular machine were no longer defined? I assume: substitute with a close match (after figuring out how do determine what counts as "close") & hope that the VMs (all Fedoras & Ubuntus) cope & adjust?
All pc-i440fs-* machine types are pretty close and based on the same chipset. There are some differences between them (e.g., in migration format, enabled CPU features for a given CPU model), but nothing an OS installed in the VM couldn't cope with. Even Windows can deal with it, but reactivation may be needed after changing the machine type. So unless you would need to stick with a specific (or old enough) machine type for migration compatibility with hosts that were not upgraded yet, you would likely end up replacing "pc-i440fx-1.6" with plain "pc", which would be expanded to the default machine type, i.e., the most recent pc-i440fx machine type supported by the installed version of QEMU. Jirka
participants (5)
-
Erik Skultety -
Jiri Denemark -
Laine Stump -
Marcin Struzak -
Michal Privoznik