On Wed, Jan 10, 2018 at 11:13:28 +0100, Kashyap Chamarthy wrote:
On Wed, Jan 10, 2018 at 09:51:19AM +0100, Pavel Hrdina wrote:
> On Tue, Jan 09, 2018 at 08:28:20PM +0100, Jiri Denemark wrote:
> > On Tue, Jan 09, 2018 at 19:44:18 +0100, Kashyap Chamarthy wrote:
> > > On Tue, Jan 09, 2018 at 04:37:10PM +0100, Jiri Denemark wrote:
[...]
> One additional note for that virt-install command, this is the cpu
> part of XML definition created by virt-install:
>
> <cpu mode="custom" match="exact">
> <model>Broadwell</model>
> </cpu>
>
> The cpu model will be different based on the host HW, but
> as you can see, there is no "check='full'.
Noted. The admin has noticed the difference between the offline and
run-time definitions
> You can verify it by appending "--dry-run --print-xml" to your
> virt-install command which will do nothing and only print the
> XML definition.
Yep, this too the admin is aware.
Aside: is it expected that the run-time and offline config is
intentionaly different for the 'check' attribute?
Yes.
Run-time:
$> virsh start vm1
$> virsh dumpxml vm1 | grep check
<cpu mode='custom' match='exact' check='full'>
^^^^
This will make sure that the CPU will not change at all (no features
added or removed) when the running domain is migrated, save/restored, or
snapshotted and reverted.
Offline:
$> virsh destroy vm1
$> virsh dumpxml vm1 | grep check
<cpu mode='custom' match='exact' check='partial'>
This is needed for backward compatibility (old libvirt allowed you to
ask for some features if they were present in host CPU even though
QEMU/KVM did not support them) and to mitigate the differences between
libvirt's and QEMU's versions of CPU models (which may even differ based
on machine type). Once the domain is started, libvirt notes all the
small differences in the XML and changes check to 'full'.
(Tried with: libvirt-daemon-kvm-3.7.0-2 and
qemu-system-x86-2.10.0-4.)
[...]
> > > sed -i -e "s-</cpu>-<feature policy='require'
name='vme'/></cpu>-"
> > > sed -i -e "s-</cpu>-<feature policy='require'
name='arat'/></cpu>-"
> >
> > This is some strange mangling of the XML by the admin for unclear
> > reason. It would be nice to finally see what the admin wanted to
> > achieve, what steps they did, and what result they saw.
>
> Agreed, this is a mess.
No, the XML updating is not the "mess" (that was required in his case).
The mess is how all this is subtly opaque to the admin.
> Just a note, if you need to edit XML
> and you would like to automate it, you can use virt-xml:
>
> virt-xml $domain --edit --cpu require=vme,require=arat
Yes, I already pointed that to the admin when he showed the `sed`
variant.
> Anyway, it shouldn't be needed to modify the XML in the first place.
It _was_ needed in his case (where updating QEMU broke).
It shouldn't be needed in any case though. It's either a bug or
something wrong they did before.
Jirka