roeland wrote ------------------------ I have the feeling that we're at slight odds semantically. What do you actually mean with local/remote? One parsing of your email seems to suggest that you're set with a keyboard and mouse plugged into your server, rather than connected via SSH, perhaps clarify with desktop/local server/remote server? -------------------- exactly true. I shut off ssh to the server and am solely using the ipmi card interface. It is like sitting at the computer with a keyboard, mouse, and monitor connected. This allows me to access the server from any computer should a need arise (the host that is) and deal with an issue without installing some software on a friends computer. The virtual guests will all have shells (well, the website ones will). I am not using a remote server for anything. I am using my home computer as a test of remote stuff with ssh still enabled, but it is all local...or trying to be. If you take a X forward or VNC program...and run it ssh from a remote computer...and are sitting at the server with a monitor+KM plugged in, logged in to the same account you will see what the manuals say is true.. the vnc and x11 forwarding run on the server, export the display remotely, then 'mostly kill' themselves when done. This precludes having an iso located on the server, using virt-install, to load up guests without using virt-manager. The only other option is to have a remote server (or home server) with the OS for guests, and have your server access it via nfs, ftp, or http. At least for fresh installs. Virt-install cannot use a local iso (meaning on the server). At least not completely, it needs a remote to make it happen. rhel6 has listed bugs for certain video cards, onboard ones, ati-nvidea-intel are listed. not all, but some. I have one. With these cards some basic things won't work (like the basic x and gnome stuff the virtual host package installs). To get any kind of x display with these cards you have to install x windows system, run the x configure that will make a x.conf.new file "only for that user", that must be 'somehow' changed for device, mtrr, etc..and add nomodeset to the kernel, etc....just to get a partial ability to use some x...but it still crashes out of it a lot. The only way I could get any gui with the video card I have is to install a minnimal desktop on top of the x windows i had to install. Red hat is saying that by 6.2 they hope to have fixes for these, but for centos that could mean a year or more before I see them. Since I had to put more of a full X system and a minimal desktop just to have the ability to remotely display the gui's then I might as well use them locally. You just 'startx', it runs a small gnome, use virt-manager, get it done, ctrl-alt-backspace out of it. In all my testing trying remote vnc and x11 with the host, as per the manuals, they only export the display on the host for that user. If the X11 or VNC display crashes out/unable to display on the host, it cannot be transferred out to the remote client. You can see this is true by simply logging into your server locally, sitting right at it...and then log in remotely with same user and do your remote stuff. You will see how the host actually does run it all and then 'copies/exports' the display. I wanted to stay pure command line, but without the ability to locally use an iso it demands virt-manager anyway. For my server video card, that means I need x and a small desktop temporarily. Once the systems are set up I will probably just remove both x and desktop anyway. Virt-install, when trying to use a local iso file, will look for boot.iso and not find it. You cannot make a bootable mounted iso on your harddrive. You would need to use virt-manager (which must do some kind of temporary bootstrap/virtual nfs) or use the local iso with a remote system called to (nfs, ftp, http) like your would with netinstall. The ipmi card affords me the opportunity to do this as if I was sitting at the server. I prefer this method as I can disable ssh port completely for the host, leaving all incoming ports for the host closed. Leaves just the ipmi card as the fail point, something that would be there anyway. Once one minimal install is done, you can use virsh and the other tools to simply clone it and play with the networks and no longer need to install anything. My biggest problem was why the install with virt-install was hanging. Only after reading online and books for a number of weeks did I find a small bit of info on virt-install that specifically states it cannot use a local iso for an install without also going remotely to another server..... That caused all installs to hang after they started. It caused vnc's and x11's to fail too since it never booted..it just hung. It hangs at connected/use ctrl+] to escape. It presented no error, just hung. I was surprised at this, but once found I learned that virt-manager was the only way to use a local file for full install, loaded x and a little desktop and voila. Wasn't fun. Another fun thing I learned, after crashed reboots, is LVM pools that I made in anaconda will work for a guest, but will crash system upon reboot due to them being 'mounted'. This is not quite written out in the manuals. Learned that the hard way. There are hundreds of forums with people complaining about superblock issues with their lvms and guests...now I know why. learning experience for sure, big hump. Using startx to start desktop and ctrl-alt-backspace to get out of it seems to be good. It loads its own programs and on exit kills them all. So except for the install, none of the x or desktop stuff is running at all. Ugly, but it works, purely locally with no remote needs. on to the next hump...bridging and bonding. _______________________________________________ CentOS-virt mailing list CentOS-virt@xxxxxxxxxx http://lists.centos.org/mailman/listinfo/centos-virt
