Scientific Linux desktop (VDI) in RHEV environment.
Hi folks,
I need some help here regarding VDI setup environment in RHEV.
Scenario: A group of students need to access the Scientific Linux desktops assigned as a group, to groups of students. They will access the User Portal and boot up the VM. After they are done with their work, the VM will revert back to its original settings, erasing any work they saved locally. Each individual VMs will boot up with individual hostname settings; will not be the same hostname for the 10 VMs throughout.
Simple setup but there are some questions.
-
I intend to create a pool of virtual machines based on a template with Stateless settings in place. Every other settings in pool remain default.
-
For a pool of 10 VMs, I intend to have each of the VMs booting up with customized settings such as hostname1, hostname2..........hostname10. I am stuck at this.
-
Stateless VMs doesn't seem to work.
If provisioning the VMs to students doesn't work (via virtual machine pool) as mentioned in the above method, I appreciate suggestions provided to me for this setup and its requirements. Thanks.
- Jack
Responses
Red Hat
25369 points
Welcome, Jack! I think someone here should be able to help out with this.
Red Hat
25369 points
I'm pleased to see you're getting some great advice from community experts in this discussion, but a bit concerned that you weren't able to get through to Red Hat Support. If you encounter this problem again, you can always open a support case online here: https://access.redhat.com/support/cases/new/
For what it's worth, I've had great experiences with Red Hat support. I've had teams literally around the world support me with some truly nasty problems. I've never had a problem getting through to the North America number, but that number forwards to some of the follow-the-sun sites after hours on my side of the world and I've had some 2AM calls go off in the weeds. But when that happened, the person I was working with gave me a cell number to call so we could still stay connected.
- Greg
Hi Jack,
I have been providing EL6 virtual desktops with RHEV for a while.
I believe that any VM that is a member of a pool is stateless. If the Pool Type is Automatic, then the state of the virtual disk will be rolled back without manual intervention.
You should seal your master VM before making a template. Instructions for sealing RHEL guests are in the RHEV Evaluation Guide. For virtual desktops, I skip the "touch /.unconfigured" step.
The hostnames of the EL6 guests are assigned via DHCP and DNS.
The steps are:
- Create a VM which will be the master.
- Seal the VM as per the Evaluation Guide.
- Create a Template from the sealed VM.
- Create a Pool from the Template
- Add users to the Permissions for the Pool
- When creating the Pool you specify the number of VMs to create in the Pool. (You can add more later.) Each of the VMs in the Pool is an individual VM.
Pool member VMs are provisioned automatically through the User Portal when a user clicks on the "Play" button for the Pool. At that point, the title of the Pool icon changes from the name of the Pool to the name of the member VM.
I believe that if you touch /.unconfigured then you get the configuration prompts that you refer to. If you get configuration prompts from a Pool VM without touch /.unconfigured in the sealing process, then we would have to investigate that further.
I forgot to mention that you should remove the HOSTNAME line from /etc/sysconfig/network when you are sealing the master VM.
This idea is probably a little off the wall, but what if you made an individual VM for each of those 10 users. Start them all from the same template so they're the same. Login to each VM as root and set up hostnames, making each VM unique. Shut down and snapshot each VM, so then when a user starts their VM, the snapshot moves forward and you have a point in time copy from before the boot. When the user shuts down their VM for the day - I'm not sure how to automate this - but come up with a hook that reverts the snapshot at every shutdown and then maybe another hook that creates a new snapshot at every boot. If this angle could work, then you would have individual VMs that stay virgin.
Or I might be pitching one of those ideas that seems really good late at night, not so good after the sun comes up. And I'm not sure how to automate those preboot snapshots and post-shutdown reverts, but maybe that REST API has something that might work? This capability would seem right up its alley.
I've heard the arguments in favor of having the DHCP server assign individual hostnames and such. The part nobody talks about is, how does the DHCP server know which hostnames go with which hosts (or with which VMs in this case)? The answer is, by the MAC Address. So in your DHCP server, you have to set up this ugly block of parameters for each MAC Address you care about, and then you have to keep it up with every change in virtual or physical systems. You have to know all the MAC Addresses in advance so you can configure DHCP accordingly. A bunch of VMs might be a little easier to set up this way versus physical systems - except that if each VM in one of these pools is created dynamically, how are you supposed to know their MAC Addresses in advance so you can tell the DHCP server about them? Maybe the MAC Addresses have some kind of predictable pattern? I'm writing this a little bit out of ignorance here because I haven't set up a pool of VMs like this yet.
- Greg
The auto-allocated MAC address range is specified in the MacPoolRanges property that can be accessed with rhevm-config.
RHEV-M can update a VNIC to a specific MAC address which is outside of the auto-allocation range. When you create a Pool of VMs, you can use a rhevm-shell script to update the MAC addresses to a fixed range.
After you have first set up a new Pool:
- decide on the fixed MAC address range
- update the VNICs with a rhevm-shell script
- add the MAC addresses to your DHCP configuration file
Eventually, you will want to update the VMs in the pool:
- remove Pool
- create a new Pool with the same name from an updated template
- update the MAC addresses of the new Pool with the rhevm-shell script
With this method, you can update the Pool without having to modify the DHCP configuration file.
Yes - the snapshot idea should accomplish the same goal of being stateless if there's a way to make it work. The idea is, if you're trying to reach the sky and one mountain doesn't work, maybe take a look at a different mountain.
On DHCP - the hostnames themselves don't need to be MAC Addresses. The DHCP server needs to know the MAC Address for each VM and then the DHCP configuration has a paragraph for each one with the hostname, maybe an IP Address reservation, and maybe other parameters. Windows DHCP servers might not support some of this stuff, so you may need to use Linux DHCP - but that may create a hassle on your Windows side of the house. So the statement, "The DHCP server can assign the hostname" is literally true, but doesn't tell the whole story.
The act of sealing seems to be pretty much what a system builder would do. Forget virtual machines - let's say you buy a new desktop PC from your favorite vendor and it comes preloaded with RHEL. The system builder probably sealed it the same way the documentation sugests sealing your virtual machines.
Hang on a second - those blue screens asking for information - that's probably what is supposed to happen at first login of a sealed RHEL machine. Just like Windows mini-setup. You fire up your brand new RHEL system and the first thing it does is ask you some mini-setup questions. The behavior makes sense, just doesn't work for your situation.
Here is an experiment - clone an existing RHEL VM if you have one handy. Disconnect its NIC, or maybe connect it to a different network, then boot it and login to it. Do that same touch .unconfigured step and shut it down. Fire it back up and I'll bet you get those same blue-screen mini-setup questions. I'll bet if you chase down the logic at boot time, I'll bet the startup scripting uses that empty file named .unconfigured as a flag to prompt for all that stuff.
- Greg
Red Hat
25369 points
Yup, I think binding MAC addresses with hostnames is the only way to do it. Apparently these pools have a predictable way to assign MAC Addresses?
I was a little bit loose in my language last night. The word, "hostname" has different meanings depending on context. There are DNS hostnames and the computer hostname. Or maybe a more general way to put it - what I call myself and what everyone else calls me. These are not always the same.
When the DHCP server assigns a hostname, what really happens is, the DHCP server leases an IP Address to the client and then either the DHCP client or DHCP Server tells the DNS server about it, depending on how you set it up. In your case, you probably want the DHCP server to register the client with DNS since you found a way to bind a MAC Address and hostname together. That takes care of what everyone calls calls you. I'm not sure if the DHCP client will actually modify its own hostname with a hostname command - but you don't care because this what you call yourself. If everyone calls themselves the same name, say, localhost.localdomain, but answers externally to, say, myhost{n}.example.com, then you should be OK.
(Woops, just edited a typo - changed a "@" to ".")
- Greg
From Jack:
Back to the feature of template deployment, hopefully we can have a feedback to Red Hat
to facilitate the automatic deployment of VMs; something what the competitors' product can do.
Note that the DHCP issue and somehow uniquely indentifying otherwise identical VMs created from a template is architectural. Everyone, all competitive products, have to deal with this, some how some way.
I don't know how the other guys do it, but Aram's comments about esentially setting up a pool of MAC Addresses to go along with the pool of VMs seems like a sensible way to do it.
I'd love to know how this project turns out.
- Greg
For USB redirection to an EL6 guest, the VM setting for USB Support should be set to Native.
On the client, USB redirection software has to be installed.
- For EL6 clients, the package is usbredir.
- For Windows clients, the program name is UsbClerk. For 64-bit Windows, you have to make sure that you install 64-bit UsbClerk. In case it is not installed automatically, the UsbClerk installer (usbclerk-setup.exe) is in the same folder as virt-viewer.exe. This may be in Program Files or the user's AppData\Local folder.
When USB redirection is working, the "USB device selection" option should be enabled in Remote Viewer's File menu.
Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.