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?

[...] 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/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/16/2021 12:51 AM, Michal Privoznik 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 figure out if that's supported in libvirt 6.1.0 (without installing it)?

On 2/17/2021 12:23 AM, Michal Privoznik wrote: > On 2/17/21 2:45 AM, Marcin Struzak wrote: >> On 2/16/2021 12:51 AM, Michal Privoznik 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 >> 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?