Fix supermin when kernel arch != arch (x86)
by Matthew Booth
I have a non-PAE kernel installed (arch=i586) on a machine which reports
arch=i686. This breaks the supermin helper. The attached patch makes it
look for any x86 kernel.
Matt
--
Matthew Booth, RHCA, RHCSS
Red Hat, Global Professional Services
M: +44 (0)7977 267231
GPG ID: D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490
14 years, 10 months
F-11 experience installing a CentOS guest
by Jerry James
I just upgraded to F-11 and have been trying out the new virt-manager.
I have had a few "Huh?" moments that I'd like to share in case they
help anyone else out.
The release notes say that F-11 guests now get higher screen
resolutions and absolute mouse coordinates via a USB tablet, out of
the box. I need to make a CentOS 5.3 guest, and decided to see if I
could get those same benefits. I knew the higher screen resolution
was possible, because I have been running a CentOS 5.3 guest in F-10
using explicit invocation of qemu-kvm with the -std-vga switch. I
hoped that the absolute mouse coordinates would also be possible, as
the lack of them was probably the most annoying part of using that
guest machine in F-10.
My first attempt was to lie to virt-manager about what kind of guest I
was installing. I told it that I was installing an F-11 guest, in
hopes that things would Just Work. They didn't. Still, I was able to
mostly patch things together as described below.
When I created the virtual machine, I took a look at the hardware
list. Even though I had specified an F-11 guest, there was no USB
tablet on the hardware list. I thought I was supposed to get that
automatically, just by specifying the F-11 guest. No matter; I added
it manually. Now I don't need the PS/2 mouse, so let's get rid of it.
I can't. The "Remove" button is grayed out. What's up with that?
So I installed CentOS 5.3 in the guest. For the record, if you have
SELinux on in your host machine, the CD images have to have type
virt_content_t. Something (virt-manager?) apparently set the type
correctly for me for CD #1, but I got an AVC denial and no CD visible
to the guest when I tried to change to CD #2. So I changed all the CD
image types to virt_content_t by hand and everything went okay after
that.
Installation finished. I rebooted the machine and got an 800x600
resolution screen. Darn. I looked through Xorg.0.log and found that
virt-manager gave me the Cirrus video card. I thought specifying an
F-11 guest was supposed to give me a generic VESA card. By adding a
Monitor section to my xorg.conf and playing with HorizSync and
VertRefresh, I can manage to get a 1280x800 window, but I really want
1280x1024. It doesn't appear to be possible to achieve that, though,
as the emulated Cirrus card is reporting a dot clock that can't manage
that resolution. How do I get virt-manager to give me the VESA card?
It doesn't appear to be possible to get that through the interface it
provides. Why not?
The absolute mouse coordinates did NOT work when I first installed the
machine. Once I added the Monitor section, they started working. I
don't know why, though, as Xorg.0.log says that it is using the
ExplorerPS/2 protocol, which suggests that X is using the PS/2 mouse
that virt-manager won't let me remove instead of the USB tablet that I
added manually.
Thanks for all the work that has gone into improving the F-11
virtualization technology.
--
Jerry James
http://www.jamezone.org/
14 years, 10 months
Fedora-virt
by Gerry Maddock
Hey all, just wanted to send a big THANKS to all developers involved in
RH/FC virtulization. I have been using it since F10 and have 3 production
W2k3 servers running rock solid on it (qemu-kvm) and I'm about to add 1
more W2k3 and 2 F11 virt servers. Keep up the good work!
14 years, 10 months
F12 feature: Host information
by Richard W.M. Jones
I posted this page on the wiki last week, which is a feature we intend
to implement for Fedora 12:
http://fedoraproject.org/wiki/Features/Hostinfo
Any comments?
Rich.
"Allow a virtual machine to see information and statistics from the
host operating system, under narrow and strictly controlled conditions
and only at the discretion of the host administrator.
Detailed Description
Allow a virtual machine to look at host information (such as number of
physical, not just virtual CPUs), and statistics like the load on the
host. Users have asked for this primarily as a diagnostic tool -- for
example, poor performance of a virtual machine might be caused by
excessive load on the host.
Normally we try to isolate virtual machines from accessing any such
details from the host, and there are very good reasons for that too,
such as security of the host, commercial confidentiality, and the
privacy of other virtual machines running on the host. As a result, at
the moment there is no mechanism for accessing host information.
We propose to add a feature which allows the host administrator, at
their discretion, and only of limited data to limited virtual
machines, to export host information and statistics to virtual
machines.
Administrators will need to:
* explicitly enable this feature,
* select the virtual machines and/or data they wish to be seen in guests,
* select the frequency that guests can ask for data.
The mechanism will be a daemon running on the host which collects the
statistics (see below for what). The information will be exported to
guests over a spare (virtual) serial port or through the qemu/kvm
vmchannel feature, whichever is available.
Guests will request information by sending a plain text command to the
serial port, and will receive information in the form of a simple,
plain text message. No special drivers or software are required by the
guest.
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
New in Fedora 11: Fedora Windows cross-compiler. Compile Windows
programs, test, and build Windows installers. Over 70 libraries supprt'd
http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw
14 years, 10 months
libguestfs experimental build with supermin appliance
by Richard W.M. Jones
This is an experimental rebuild of libguestfs with the supermin
appliance:
http://koji.fedoraproject.org/koji/taskinfo?taskID=1418138
Make sure you install libguestfs >= 1.0.48-2. Earlier versions were
broken in various different ways.
I've tested it locally on i586 & x86-64 and it seems to work for me.
You'll get warning messages like this:
><fs> alloc /tmp/test.img 10M
><fs> run
cpio: ./usr/sbin/glibc_post_upgrade.i686: Cannot open: Permission denied
cpio: ./usr/sbin/groupadd: Cannot open: Permission denied
cpio: ./usr/sbin/groupdel: Cannot open: Permission denied
cpio: ./usr/sbin/groupmems: Cannot open: Permission denied
cpio: ./usr/sbin/groupmod: Cannot open: Permission denied
cpio: ./usr/sbin/tzdata-update: Cannot open: Permission denied
[etc.]
This is a known problem (it tries to pull some files from the host
filesystem which are not readable) and shouldn't affect any operations
and it still passes the test suite even without those programs.
Rich.
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v
14 years, 10 months
handling guest-service dependencies at boot time elegantly?
by Bill McGonigle
Hi, all,
Before I start hacking up my own poor solution, I'd like to run this by
the list and see if there's a good way to handle this.
I have a host (5.3 Xen Dom0) that has three guests:
Fedora 10
Fedora 11
Nexenta 2
The Nexenta (opensolaris) guest's job is to provide storage services to
the Fedora DomU's, via iSCSI and NFS (ZFS storage).
My goal is to automate system startup.
My dependency tree looks like:
Dom0 -> nexenta-DomU -> 'service iscsi'@Dom0 -> fedora-DomU's
Currently I have xendomains and iscsi set to 'chkconfig off' and the
fedora DomU's set for 'auto', and do:
xm create nexenta
[watch xentop to see when it's running]
service iscsi start
service xendomains start
Which works find and requires me to do it. I can write some scripts to
do the same thing, but if there was a more general-purpose way to
express these kinds of boot-time dependencies, I'd rather do it right.
I was thinking perhaps upstart could be co-opted for this purpose, if I
can make it not cobbler init (it would have to run alongside on 5.3).
Are there any libvirt event hooks into upstart?
Thanks,
-Bill
--
Bill McGonigle, Owner Work: 603.448.4440
BFC Computing, LLC Home: 603.448.1668
http://www.bfccomputing.com/ Cell: 603.252.2606
Twitter, etc.: bill_mcgonigle Page: 603.442.1833
Email, IM, VOIP: bill(a)bfccomputing.com
Blog: http://blog.bfccomputing.com/
VCard: http://bfccomputing.com/vcard/bill.vcf
14 years, 10 months
RFC: libosinfo: Library for virt OS/distro metadata 3
by Cole Robinson
Hi all,
I've done the initial work for a new library, libosinfo (better name
recommendations appreciated). This library will provide OS meta data for use
in virt applications, replacing the dictionary we currently keep in virtinst.
This is based off of a post by Dan Berrange:
https://www.redhat.com/archives/et-mgmt-tools/2009-March/msg00028.html
The code can be fetched with:
git clone http://fedorapeople.org/~crobinso/osinfo/.git
Check out the TODO list for a simple roadmap.
http://fedorapeople.org/~crobinso/osinfo/TODO
The public API looks like:
/**
* Values stored in the OS dictionary
*/
enum _os_value_type {
OS_VALUE_NAME = 1, /** Human readable family/distro... name */
OS_VALUE_MEDIA_INSTALL_URL, /** URL to an install tree */
};
typedef enum _os_value_type os_value_t;
int os_init();
void os_close();
int os_find_families (char ***list);
int os_find_distros (const char *parent_id, char ***list);
int os_find_releases (const char *parent_id, char ***list);
int os_find_updates (const char *parent_id, char ***list);
int os_lookup_value (os_value_t value_type,
const char *os_id,
char **value);
The unique identifier for each distro is its 'id', which is a simple human
readable string, similar to values we use for virt-install --os-variant today.
The user will ask the API for available families/distros/releases/updates,
which will return a list of ids. We then pass an id to os_lookup_value to
actually retrieve data. The family/distro/... separation will likely be
removed pretty soon, in favor of an arbitrary hierarchy, where every OS
can have child OSes: no doubt hardcoding the family/distro/... split would
come back to bite us in the ass.
As an example, the following code will list the 'Name' of every id at
the'family' level, where name is full name of the OS (id = rhel5.3, name = Red
Hat Enterprise Linux 5.3):
char *value = NULL;
char **namelist = NULL;
int i, num_fams;
if (os_init() < 0)
goto error;
if ((num_fams = os_list_families(&namelist)) < 0)
goto error;
for (i = 0; i < num_fams; ++i) {
if (os_lookup_value(OS_VALUE_NAME,
namelist[i],
&value) < 0)
goto error;
printf("%s\n", value);
free(value);
}
error:
free(namelist);
free(value);
os_close();
There is a simple tool called 'osinfo-tool' which allows listing an ASCII repr
of the OS hierarchy, and listing all values for an individual id (which is
pretty sparse at the moment since most of these values haven't been filled
in yet).
So, things that I'm interested in feedback on:
- How do we expect apps to list OS choices? Currently, virt-manager lists
type (linux, windows, unix, etc.) and associated distros (Fedora 8, RHEL4,
Debian Lenny, etc.). The linux/windows/unix info isn't represented in the
xml (should it be?) so the best way seems to be:
Distro
|
--> Release
|
--> Update
Ex.
RHEL
|
-> RHEL5
|
-> 5.0
5.1
5.2
If we do away with the family/distro/... distinction, the user won't have
much choice in the matter, but the 'family' concept (e.g. value of
'Red Hat') isn't very useful to expose to a user.
- How should we handle derivatives like Scientific Linux + CentOS: should we
expect users to understand they are based on RHEL, or give them explicit
IDs?
- Querying for device values (supported buses, models, etc.). Dan's original
proposal talks about this; to recommend a default with the best chance of
actually working, we need to know:
- OS being installed
- Virt type ('hvm' vs. 'xen')
- Guest Architecture (i386, x86_64, ...)
- Hypervisor (kvm, qemu, xen, vbox, ...)
- Hypervisor version
- Libvirt version
We would need to find the intersection of what the OS, the hypervisor,
and libvirt support, and return what we decide is the best choice.
How to expose this in the API? We could simply have one long function
os_lookup_device_value(char *os_id, char *virt_type, char *arch, ...)
It works, but its pretty tedious, and I'm afraid that we would need
even more info to make a correct choice in the future, and the above
isn't flexible. We may also need some of the above info for other values
(ACPI/APIC settings, returning a proper install url may depend on arch).
Any suggestions?
- os_init and os_close: Any better ideas for this? os_init just parses the
xml document, os_close frees it. We could run os_init with the first API
call, but I think that makes it less clear that the user would then
need to call os_close().
Any feedback appreciated.
Thanks,
Cole
14 years, 10 months
iPod Touch + Fedora 11 + KVM + WinXP guest + iTunes?
by Laine Stump
I want a Win XP guest (running under a fresh F11 install) to talk to my
shiny new iPod Touch. I tried adding the "Apple Inc. iPod" USB device to
the guest's hardware list with virt-manager, but even after restarting
everything it isn't recognized (it's still picked up by the host OS -
which doesn't know what to do with it - and not seen at all by the guest).
Has anybody done this? Any hints?
(a better solution would be if RhythmBox or some other program figured
out how to talk to the Touch (and/or iPhone), but as far as I've found,
that hasn't happened yet).
14 years, 10 months
Is this normal?
by Tom Horsley
I have my newly installed fedora 11 x86_64 system on an Intel
Core 2 Duo with virtualization hardware support, so I thought
I'd give KVM a whirl.
I started virt-manager as root, defined a new machine which
I made be an i686 and pointed at the Fedora 11 i386 DVD iso
image. I also told it to allocate space immediately for a 12GB
image file.
It has now been running anaconda's cylon eyeball format
progress bar for about an hour.
How long should it take to format the silly disk image?
Other points:
I can't believe virt-manager insists on placing image files
under /var. They take lots of space. I'd expect to be able
to pick a place to put the disk image.
This fedora-virt mailing list doesn't have a pointer in the
list of mailing lists on the fedora mailing list web page
at: http://fedoraproject.org/wiki/Communicate
14 years, 10 months
