> From: Philip Rhoades
> I can ssh from/to the host/guest OK but how do I set up a route (or
> whatever is necessary) so that another machine:
> eth0: 192.168.0.12
> can ssh to the guest? - "ssh 192.168.122.68" gives "no route to host" -
> http://docs.fedoraproject.org/virtualization-guide/f12/en-US/html/ but
> the problem does not seem to be covered there.
Alexander is correct in saying that bridging would allow you to do that.
There are two networking discussed in the guide.
The first is a NAT (network address translation), in which the guests are
given "private" ip addresses and any outbound traffic appears to be coming
from the host machine's IP address. This is the same as the setup on your
ADSL router where the internal network machines get addresses of
192.168.x.x but the internet sees your requests as coming from the IP
address of your router.
There should be lots of documentation in linux firewalling guides under
sections on NAT (or possibly called IP Masquerading in some). Have a look
at these for information on port forwarding to reveal services
inside the virtual (such as ssh).
The other option is bridging. This shares the physical network interface
of the host with the guest. In this case the VM acts as though it's a
machine plugged into the same subnet as the host, its services are
accessible like those of the host and it's as vulnerable to attack as the
I am trying to work out whether it is practical to propose Dom0 xen
support as a feature for Fedora 15.
The kernel situation is that Domain 0 has been accepted upstream for
2.6.37. Assuming a 3 month kernel release cycle, F15 will most likely ship
with a 2.6.37.x kernel, with 2.6.38 coming out either after the F15
release or just before but too late to be included. If the plan to get key
xen drivers into 2.6.38 succeeds, then F15 may be become usable as a
Domain 0 system at some point during its lifetime as the kernel package in
a Fedora version typically has one major update.
If the kernel team accept backported patches then it might just be
possible to ship F15 with usable Domain 0 support but the timescale for
that would be very tight.
The other thing we would need to consider is what needs to be done to make
xen friendly enough to be usable by an ordinary user. The page
https://fedoraproject.org/wiki/Features/XenPvopsDom0 contains plans from
when dom0 xen support was expected to make a quick return to Fedora, but
they are a couple of years old now so probably need updating.
I think as a minimum we would need a way to add a dom0 enabled grub entry
for a kernel, rather than requiring the user to hand edit the grub file.
We should also make sure that xen works with the other Fedora
What do others think about this? For example is it achievable as a
feature, is it too early and better to wait for F16, and what else should
we aim to do to make xen usable in Fedora?
As far as I can see this issue is being ignored. See the link below.
Apparently this has been fixed since last October and the person this has
been assigned to did the package update for Fedora-14.
Cole Robinson said it should be fixed for Fedora-13. See comment 45. The
current packages date from August 2010 so they definitely have not been
qemu-0.12.5-1.fc13.x86_64.rpm12-Aug-2010 11:04 23K
qemu-common-0.12.5-1.fc13.x86_64.rpm12-Aug-2010 11:04 242K
qemu-img-0.12.5-1.fc13.x86_64.rpm12-Aug-2010 11:04 146K
qemu-kvm-0.12.5-1.fc13.x86_64.rpm12-Aug-2010 11:04 22K
qemu-kvm-tools-0.12.5-1.fc13.x86_64.rpm12-Aug-2010 11:04 33K
qemu-system-arm-0.12.5-1.fc13.x86_64.rpm12-Aug-2010 11:04 880K
qemu-system-cris-0.12.5-1.fc13.x86_64.rpm12-Aug-2010 11:04 560K
qemu-system-m68k-0.12.5-1.fc13.x86_64.rpm12-Aug-2010 11:04 601K
qemu-system-mips-0.12.5-1.fc13.x86_64.rpm12-Aug-2010 11:04 2.9M
qemu-system-ppc-0.12.5-1.fc13.x86_64.rpm12-Aug-2010 11:04 2.6M
qemu-system-sh4-0.12.5-1.fc13.x86_64.rpm12-Aug-2010 11:04 1.1M
qemu-system-sparc-0.12.5-1.fc13.x86_64.rpm12-Aug-2010 11:04 623K
qemu-system-x86-0.12.5-1.fc13.x86_64.rpm12-Aug-2010 11:04 2.3M
qemu-user-0.12.5-1.fc13.x86_64.rpm12-Aug-2010 11:04 4.0M
Virtualbox usb works extremely well on Windows xp vm on top of fedora...
would think it works as well as that on linux-based vm. Though u must use
the vbox extension which is license under puel.
On Dec 31, 2010 5:34 AM, "EB30750" <eb30750(a)gmail.com> wrote:
I have not used virtualization in Fedora recently. I would like to set
up a Ubuntu virtual machine on Fedora 14 x86_64. If I do this, it will
become very important for the Ubuntu machine to have access to USB
devices connected to the host. Often this will be done over a USB/serial
cable. Is this doable?
Here is the reason. I am just starting to learn how to work with Gumstix
hardware. To build Angstrom OS images for that, I have been using
Fedora 14 as a build host, but I am thinking it might be better for me
to create a Ubuntu virtual machine and move all my Gumstix and
Openembedded work onto the Ubuntu system. Gumstix itself seems to
recommend doing all development work on Ubuntu.
 The Gumstix platform of computer-on-module devices:
So, if I wanted to turn a Windows KVM into a utterly safe
web browser machine in which I revert the copy on write
filesystem on each boot, what is the best way to also isolate
it from the rest of the local network?
I've got all my KVM machines setup with bridge networking
right now. Can I use some magic firewall rules to prevent
one specific virtual machine from having any access to
my local network? (While still allowing the spice display
and mouse to operate, of course :-).
Configure it on a separate subnet maybe and use NAT on the
KVM host to allow it access to the outside world?
As mentioned in one of the comments a fix is supposed to exist. I was also
told at some point that new packages would be forth coming. That was a while
ago. So what is the current state of the work being done, if any, to come up
with a fix?
Also there was a comment about using the Fedora-14 packages. Any
instructions on how to replace the Fedora-13 rpm's with the ones for
Fedora-13? I have several VM's installed and I don't want to hose-up the
ones I have.
Hi Since reinstalling my virt-host to F14.
My guest VM's are jerky, like as thought the screen is being refreshed
after every action.
The only thing, I came across was a line in messages ( on an F14 guest)
"booting kernel test 03: booting para-virtualized kernel"
With Virt built into the CPU, should I not get full virtualization.
What else shoul I be looking at.
Host is Intel quad-core with 4gb ddr2 ram.
With 1gb of guest hd space spread across 3 physical drives.
Friend of Fedora
We are pleased to announce the next stable release of libguestfs,
tools and a library for accessing, creating and modifying the contents
of virtual machines and disk images.
Home page: http://libguestfs.org/
Binary packages for:
RHEL 6: http://people.redhat.com/~rjones/rhel6.1-libguestfs-preview/ (soon)
Here are the release notes (also at http://libguestfs.org/RELEASE-NOTES.txt )
Release notes for libguestfs 1.8.0
These release notes only cover the differences from the previous
stable/dev branch split (1.6.0). For detailed changelogs, please see
the git repository, or the ChangeLog file distributed in the tarball.
- Support and packages for Debian and Ubuntu.
- Daily builds from git repository on Debian and Ubuntu to reduce risk
- Port to ArchLinux 'pacman' (thanks Thomas S Hatch).
- The following tools have been rewritten in C (originally in Perl):
- Some C tools support encrypted guests automatically. This is
supported in: guestfish, guestmount, virt-cat, virt-inspector,
- New tool virt-filesystems (in C) which is a replacement for
virt-list-filesystems and virt-list-partitions, and has a superset
of the functionality of those tools.
- guestfish, guestmount and the C tools use unified command line option
parsing, so they support many common options such as '-a disk.img',
'-d libvirt-domain', '-x', '-v'. The old command line option
parsing is preserved for compatibility in scripts etc.
- guestfish no longer has any dependencies on Perl
- New man pages containing programming examples: guestfs-examples(3) (C/C++),
guestfs-ocaml(3), guestfs-python(3), guestfs-ruby(3).
- Trace mode prints return values from API functions.
- virt-inspector can list applications installed in Windows guests, along
with a great deal of information about those applications.
- Add support for inspecting: Linux Mint, Mandriva, FreeBSD.
- guestfish --rw option (with no effect currently) to make potentially
dangerous write access explicit.
- guestfish --listen --csh for compatibility with csh, tcsh (thanks
- The first upstream version that introduced each API function is now
documented in guestfs(3).
- guestfs_last_errno allows you to retrieve the errno from the
daemon, correctly translated to the local operating system.
- Functions can now have optional parameters.
- Progress bars and progress notifications can now happen for upload
- Appliance builder more careful about not leaving temporary files
around in /tmp.
- getfattr/setfattr commands added to virt-rescue.
- ROADMAP file covers roadmap and goals for future releases.
- New SECURITY section in guestfs(3) API documentation.
- virt-inspector no longer runs any guest commands.
- Inspection code is more careful about avoiding very large files
from guests which might previously have caused a denial of service.
- FUSE calls into guestmount are now traced when using guestmount -x.
- C programs now only link precisely with the libraries that they use.
- PCRE, libmagic, hivex and libvirt libraries are now completely
optional for building.
- Multiple memory leaks and file descriptor leaks fixed.
- Add a POD wrapper to unify generation of man pages and HTML files
across all programs.
- Source includes phony images of Fedora, Debian, Ubuntu and
- Ruby bindings have 'make install' rule.
- <guestfs.h> is now a single file.
- <guestfs.h> does not require XDR headers.
- ocaml xml-light library is no longer required to build (thanks
- ./configure --disable-[...] for each language binding (thanks
- Old ocaml-viewer program removed (use guestfs-browser instead).
- New C API test type 'InitScratchFS' makes the tests run a little
- Excluded packages in the appliance are now listed in a separate
file appliance/excludelist.in, and can be customized per-distro.
- 663407 readlink and readlinklist returns /sysroot/ in some paths
- 661280 virt-rescue: panic when shutting down: "/sbin/reboot: No such file or directory"
- 657499 checksum: wrong check sum type causes umount to fail
- 655554 Whole disk paths are not made canonical by virt-inspector
- 654638 openssl updated to 1.0.0b libguestfs depends on exact file names
- 652796 ruby bindings not installed by 'make install', hence omitted from the binary distribution
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
Is there some conspiracy to obfuscate the best place to
find windows guest spice drivers? People seem to invent
random names for the files, so you don't know if
it is an update of something with a old name or not.
Sometimes there are .iso files, sometimes .zip. Most of
the web pages offering downloads don't have dates,
so you can't tell which are the latest versions.
Why is this so hard?
Are the spice-space.org versions on the downloads
page always the best versions to grab? And if so,
what the heck do I actually need? I know qxl
is for video, but what the heck do the other
windows binaries actually do? Why do I want them?
I found a file named kvm-guest-drivers-windows-061510.iso
when testing a while back and it seemed to work, but
also seems likely to be pretty old these days.