I'm upgrading a prehistoric fedora13 machine that hosted a gazillion virtual machines to centos 7.
I find that the old virtual machine xml files make the new libvirt barf.
I can get a good idea of how to fix all the old xml by installing a new file and comparing things, but I wonder where this magic comes from:
<os> <type arch='x86_64' machine='pc-i440fx-rhel7.0.0'>hvm</type> <boot dev='hd'/> </os>
Specifically, the "machine" definitions. Should that just always be the string above since my host is centos 7?
On 08/13/2014 06:31 PM, Tom Horsley wrote:
I'm upgrading a prehistoric fedora13 machine that hosted a gazillion virtual machines to centos 7.
I find that the old virtual machine xml files make the new libvirt barf.
I can get a good idea of how to fix all the old xml by installing a new file and comparing things, but I wonder where this magic comes from:
<os> <type arch='x86_64' machine='pc-i440fx-rhel7.0.0'>hvm</type> <boot dev='hd'/> </os>
Specifically, the "machine" definitions. Should that just always be the string above since my host is centos 7? _______________________________________________ virt mailing list virt@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/virt
Hi Tom,
The "machine" definition is taken from qemu-kvm. If you don't specify the machine in XML configuration the default machine type from qemu-kvm will be used.
To get currently supported machine types you can run "virsh capabilities". Default is "oc" which is translated into the long name and in case of centos7.0 it is "pc-i440fx-rhel7.0.0".
Pavel
On Wed, Aug 13, 2014 at 12:31:35PM -0400, Tom Horsley wrote:
I'm upgrading a prehistoric fedora13 machine that hosted a gazillion virtual machines to centos 7.
I find that the old virtual machine xml files make the new libvirt barf.
I can get a good idea of how to fix all the old xml by installing a new file and comparing things, but I wonder where this magic comes from:
<os> <type arch='x86_64' machine='pc-i440fx-rhel7.0.0'>hvm</type> <boot dev='hd'/> </os>
Specifically, the "machine" definitions. Should that just always be the string above since my host is centos 7?
Slightly OT, but if you guest is _not_ Windows then you can just drop the machine=... attribute and libvirt will pick a suitable one next time the guest starts.
For Windows, the machine type is needed to ensure stability of the virtual hardware so that Windows doesn't try to reactivate itself. Other OSes don't suffer from this problem.
Rich.