> 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'm trying to install XP with virt-manager-0.8.5-1.fc14.noarch. XP
setup gets to the point of copying the files to the .img. Then I get a
quick flash that I think says something like VNC lost connection with
If I reboot from the disk, I get "Error loading operating system". If
I reboot from the CD, it tells me the .img file is corrupt and needs
to be reformatted. Then I'm back to my original problem.
Is this the right list for this problem? If not, where do I go?
Relatively new to virtualzation so bear with me..
Do we have somewhere good document on on how to setup virtualzation
environment that supports migration.
I just set up 3 blade servers for testing.
I installed on all of them RHEL 6 Beta and the virtualsation packages.
Created ssh keys and allow the machine to connect all to each other.
Created a storage pool on SAN that is shared by all the hosts and
mounted under /var/lib/libvirt/images ( default storage pool )
Created a RHEL 6 Beta test VM on one of the server with virt-manager (
0.8.4-3.fc13 ) on F13 and that VM image is present to all blades under
the default storage pool.
When trying to migrate that image to one of the 2 other servers with
virt-manager it fails with following error on the host it's being
libvirtd: 10:11:44.682: error : qemudDomainBlockStats:9678 : Requested
operation is not valid: domain is not running
libvirtd: 10:11:44.684: error : qemudDomainBlockStats:9669 : Domain not
found: no domain with matching uuid 'd7aae419-ed79-12cf-3597-6a0b067eef79'
libvirtd: 10:11:44.686: error : qemudDomainInterfaceStats:9741 : Domain
not found: no domain with matching uuid
So somewhere along the line I forgot to configure and start the domain
or is this a bug or compatibility issue with virt-manager-0.8.4-3.fc13
and RHEL 6 ?
----- Forwarded message from Keir Fraser <keir.fraser(a)eu.citrix.com> -----
From: Keir Fraser <keir.fraser(a)eu.citrix.com>
To: "xen-devel(a)lists.xensource.com" <xen-devel(a)lists.xensource.com>,
Date: Wed, 25 Aug 2010 09:32:12 +0100
Subject: [Xen-devel] Xen 4.0.1 released
RELEASE-4.0.1 has been tagged in http://xenbits.xen.org/xen-4.0-testing.hg
Browsing the above URL will show the mercurial changelog contains many many
bug fixes since 4.0.0. We recommend all users to upgrade.
A source tarball will soon be available from
Xen-devel mailing list
----- End forwarded message -----
I'm happy to announce two new releases:
virt-manager 0.8.5: virt-manager is a desktop application for managing
KVM and Xen virtual machines via libvirt.
virtinst 0.500.4: virtinst is a collection of command line tools for
provisioning libvirt virtual machines, including virt-install and
The releases can be downloaded from:
The direct download links are:
The virt-manager release includes:
- Improved save/restore support
- Option to view and change disk cache mode
- Configurable VNC keygrab sequence (Michal Novotny)
The virtinst release includes:
- New virt-install --console option for specifying virtio console device
- New virt-install --channel option for specifying guest communication
- New virt-install --boot option. Allows setting post-install boot
order, direct kernel/initrd boot, and enabling boot device menu.
- New virt-install --initrd-inject option, which enables installation
using a _local_ kickstart file (Colin Walters)
Thanks to everyone who has contributed to this release through testing,
bug reporting, submitting patches, and otherwise sending in feedback!
What is the cleanest approach to export a vm (disk image along with
associated xml file) to an external media, then re-importing that vm
back into virt-manager? Some combination of virt-create with --import
I've got some test vm's that I made clones of, and I would like to
back them up to an external source and reimport them at a later time
should I need to.
I have a virtio disk for a vm that consists of an lvm.
I would like to port this vm disk to another virtualization host that has vm
disks on file, instead.
Can I port this lvm vm-disk to file, for example with something like:
dd if=/dev/vgname/lvname of=/directory_tree/filename
and then copy "filename" to the other host and use it as a backing storage
for a vm on it?
Do I have perhaps to consider some heading for lvm metadata and skip
anything form the dd command?
Anyone already done/considered?
being in fc13 and installing today the virt-preview repo packages, I
was hoping to get qxl vga device available as option in virt-manager
In fact I see that qemu has been updated to 0.13 version from
pre-existing 0.12 in stock FC13.
Correct? or if I want to test spice I have to run from command line my
guests? In this case which interaction with pre-existing ones managed
BTW, if merge in virt-manager of virt-preview repo is planned for qxl
vga, should I "simply" see the option when I try to modify hw for a
previous gest (aka created in FC13 0.12 qemu) or should I have to
change virtual hw in xml file for the guest or in other files?
Thanks in advance,