This could cause issues for people trying unattended non-graphical
kickstart installs and expecting ttyS0 in the guest to be hooked
up to the default console. So to get back the default behavior, you
can do:
--console pty
The XML we use is:
<clock offset="utc">
<timer name="rtc" tickpolicy="catchup"/>
<timer name="pit" tickpolicy="delay"/>
<timer name="hpet" present="no"/>
</clock>
Which translates to the qemu commands:
-no-hpet -no-kvm-pit-reinjection -rtc driftfix=slew
The latter two bits are already used by openstack and gnome boxes by
default.
On RHEL hpet is compiled out so -no-hpet is the default,
but not everywhere else. Though recently the RH guys confirmed that
for regular usage it should be turned off because a) qemu support
is not that good, b) most users don't need it anyways c) it has
a performance penalty.
This default can be overridden from a virt-install command like
--clock rtc_tickpolicy=delay
When Guest() sees that a timer has already been defined, it won't
set the new defaults, and that setting above is the old implied
default rtc setting.
These bits only apply if virt-manager is running directly on a RHEL6.
Since latest virt-manager can't do that thanks to GTK3 conversion,
just drop it all.
Currently only QEMU is supported so we only show the check box when
it's used. The future-proofing is that we'll show it for an explicitly
set non-default value, even for hypervisors we don't think support it.
This used to happen:
- create VM with cdrom, cdrom gets hdc
- customize before install
- add new cdrom, gets target hda or hdb (first free target)
- new cdrom now has priority in the boot order
Change the logic to try to append targets first, and if there isn't
any space left, use the first free one. This may cause other issues
but we'll just have to wait and see.
It was required a long long time ago, before qemu supported -drive
and possibly ancient xen. Nowadays it should be pointless, and contributes
to some issues like bz 905439
