IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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.
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
This is where performance issues hit the most. This changes the
RHEL default to remove cache=None for all file volumes. If anyone
cares they can speak up, but it seems an overly unnecessary deviation
from upstream qemu.
qcow2 enables fancy features like snapshots and is generally more
desktopy, which we purport to be.
We only do this on not horribly old libvirt/qemu, and only on qemu
connections. This may work for xen but I'm not going to turn it on
until someone tests it.
Moving name to the end allows us to do things like generate a default
name based on the chosen OS type, which we do here. This is bz 736951
Moving arch/type to the front page of the wizard simplifies validation
and will be needed to intuitively install arm guests without a bunch
of hacky workarounds.
According to the changelog of libvirt http://libvirt.org/news.html,
the required version for stream console should be 0.8.6.
Please check the link: http://libvirt.org/news.html, libvirt started
to support virDomainOpenConsole() since "0.8.6: Nov 30 2010". And there
were also many changes related to stream console.
In practical terms, I have tested the change with libvirtd-0.8.8 in
Ubuntu 12.04.2 (x64) and another ARM port libvird-0.8.8. I think changing
to 0.8.6 should be fine because according to the changelog there are
no big changes in libvirt-0.8.7 and libvirt-0.8.8.
Signed-off-by: Ying-Shiuan Pan <yspan@itri.org.tw>
We sort them separately in the snapshot list, explicitly mention that
they are 'external', and add a UI field listing the memory/disk
details.
In general mixing internal and external snapshots is a recipe for
confusion and disaster, so I think the best thing to do is at least
acknowledge their presence in the UI but not make any attempt to
predict what will or will not work.
This could cause issues if something like a domain support check
returns NOSUPPORT for one domain on a connection but not for another
domain, but honestly I'd call that a libvirt bug since NOSUPPORT should
be usable like we want it.
