[libvirt-users] Virtualizing a an old SuSE system

[Dale Amon]

On Mon, Feb 27, 2012 at 05:41:49PM -0700, Eric Blake wrote:
> On 02/27/2012 05:15 PM, Dale Amon wrote:
> > On Mon, Feb 27, 2012 at 11:14:41AM -0700, Eric Blake wrote:
> >> On 02/25/2012 07:42 PM, Dale Amon wrote:
> >>> I'm in the midst of an attempt to convert an
> >>> old and rather large SuSE server (5 disks) into
> >>> a virsh loadable VM. Has anyone else dealt with
> >>> the issues of systems of this sort? I'm at the
> >>> moment trying to hand construct a machine xml
> >>> file for it. I managed to create one which would
> >>> load but not start.
> >>
> >> Personally, rather than trying to hand-create XML, I've found it handy
> >> to use virt-manager's ability to create a new machine XML description
> >> around existing disk images.  That is, use virt-manager to create a new
> >> VM, but instead of telling it to install the new machine from scratch,
> >> you instead tell it to attach to the pre-existing storage of the
> >> eventual guest, and the OS that is installed in that storage, and it
> >> generates pretty good defaults for the XML that will then boot that guest.
> > 
> > Hmmm... this is a very remote (from me) virtual host server.
> > I can get a remote xterm but it throws a fit when I try to
> > run virt-manager as root over ssh.
> > 
> >  ERROR:root:Unable to initialize GTK: could not open display
> > 
> > Suggestions?
> 
> Run virt-manager locally, and tell the local virt-manager to connect to
> the remote qemu+ssh://root@remote/system, rather than trying to run a
> remote X virt-manager.  (Same goes for things like 'virsh -c
> qemu+ssh://remote/system' rather than ssh to remote before doing 'virsh
> -c qemu:///system')


virt-manager --connect qemu+ssh://root@myhost.domain.net

fails to connect.

	Unable to open a connection to the libvirt management daemon

I know that I have used similar commands on other machines
a year ago... I checked my notes. I'm on my laptop doing
this and attempting to connect to a production machine 4000
miles away, ie my options are limited and I cannot really
fiddle with the server there without having a teleconference
first and having everyone sign off that doing X will definitely
not affect any customers... I'm sure you know the drill for
production machines.