enterprise server licensing question - what is virtual ?
Linux - GeneralThis Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then this is the place.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
enterprise server licensing question - what is virtual ?
I'm looking at some servers at dell and you can choose either redhat or suse for the operating system. SLES and RHEL to be specific.
SLES for example you can get n year subscription, as a physical license or as unlimited virtual licenses.
for RHEL the wording is 1 or 4 virtual guest, and does not offer an unlimited virtual license.
the licensing having the virtual stuff costs more.
can someone explain what/where/why/how you would use the virtual stuff?
Virtual machines can be very useful for many different tasks. They're basically full operating systems that run on "fake" hardware inside your main operating system. As far as they're concerned, they're real computers, and they act like real computers. They have an IP on your network like a real computer does, you can ssh into/out of them like normal, they can host services like real computers do. A backup is requires little more than one command to make a snapshot, or you can shut down the VM, copy the file that contains the drive to a backup, boot it back up, and then at any time you can simply restore the backup, boot it up, and it will be running exactly as it was when you made the backup.
What are they useful for? They're good for running dedicated services that you might want to be portable. Say a DNS server for your network. You could set up your main machine to perform DNS duties, but what happens when one of its other tasks or a piece of hardware requires some maintenance, which forces you to shut off the machine? You now lose your DNS for the network. If instead you have a virtual machine running DNS, and the host needs some work done, you literally just shut down the VM on that machine, boot it up on another, and everything keeps working like normal with less than a minute of down time.
They're also good for security reasons. You can use a VM to host your website, for example. If a security vulnerability in your website allows a malicious user to gain access to the system, what kind of damage can they do? If this is a full machine running 100 other services, they could potentially bring down the entire thing. If it's a VM, the worst they can do is wipe that VM and bring down the website. In which case you delete that VM, restore a recent backup, boot it up, and you're back up and running literally within minutes.
They're good for testing as well. Set up a VM that's identical to the host, all of the same programs installed, all of the same services. If you want to test the effect of a patch or update, run it on the VM first. If it breaks things, restore your VM using a recent snapshot and you're no worse for the wear.
Or say you want to install a new service on your main machine, you can install a VM using the same OS, fumble through all of the steps required to get the new service up and running correctly, possibly breaking things along the way or installing more programs than necessary. Once you know exactly what's needed, use your notes to install it for real on the main machine, delete the VM, and you're done.
There are a thousand examples of useful things you can do with VMs. Above are just examples running the same OS on the VM as on the host. You can also use VMs to experiment with other distros, newer/older versions of your distro, or other OSs entirely. Need Windows for MS Office? Install it in a VM and let it run along-side your main OS so it's always available, no need for dual-booting.
The downsides are the extra resources they require, but even that is only temporary and not big anyway. Virtualization is built into modern processors, so tasks run nearly as fast on VMs as they do on bare metal. I/O and network speeds are also nearly as fast as on bare metal. RAM is really the only thing, and drive space to hold the extra OS. Both RAM and HDD space are cheap though, so the point is mostly moot. A dual core Linux system with 16 GB of RAM and a 1 TB drive could run itself and 8+ VMs simultaneously without much effort.
Last edited by suicidaleggroll; 06-23-2015 at 10:19 AM.
so let's say i have a dell rack server, model R920 with 4 12-core intel cpu's and 128GB of memory.
And it can hold up to 12 or 24 hard drives.
please walk me through the technical parts of setting up a VM.
I install hard drive #1 into the system, it's the only hard drive so far. I put Novell SLES install dvd in and begin the install. I can choose from 4 scenarios:
- physical machine (also for fully virtualized guests)
- virtual machine (for paravirtualized environments like xen)
- XEN virtualization host (Local X11 not configured by default)
- KVM virtualization host (Local X11 not configured by default)
I've always chosen the "physical machine" and installation would be typical. I use EFI so /dev/sda1 is FAT32 mounted as /boot/efi and /dev/sda2 is EXT3 mounted as /.
I don't know where to go from here regarding VM
must you always install the physical machine first on some hard drive that boots the system, then the virtual stuff goes on top of it?
must you always install the physical machine first on some hard drive that boots the system, then the virtual stuff goes on top of it?
Yes
You'd install the host system like normal, nothing changes there. Once the host system is up and running, you use some VM software (VMWare, VirtualBox, etc.) to set up a new VM. You assign it some portion of your RAM, access to one or more of your processor cores, access to one or more of your NICs, and you give it a file name to use as a "hard drive" with a fixed upper limit of XX GB. Once that's all set up, you tell your VM software to start the VM. The first thing it will do is ask for an iso file to use as a boot device, you point it to your SLES iso file, and then it pops up with a window which inside looks like a normal computer going through the BIOS verification, boots from the SLES iso, and you pick what type of installation you want to do, etc. It will "format" its "hard drive", install itself, reboot, etc. just like a real computer would. The difference is its network interface, video interface, keyboard interface, etc. are all virtual, emulated by the VM software, and its "hard drive" is just a file sitting on the host machine's filesystem.
Last edited by suicidaleggroll; 06-23-2015 at 04:42 PM.
One possible way to look at "virtualization" is that it is an extremely fine-grained form of physical partitioning. You can allocate the computer's hardware resources very precisely to one-or-more virtual machines, each one of which is not aware of the presence of any other.
Intel microprocessors have very sophisticated hardware support for virtualization, so the process is actually very efficient.
ok i think i figured some of it out playing around.
i had a blank drive and tried the install of "KVM virtualization host (Local X11 not configured by default)"
it basically installed a stripped down version of SLES onto my drive, only thing that runs is TWM.
went back to my original bootable hard drive that has my "physical machine" installation, which is the same thing as the KVM install except has the entire SLES system including X11, Gnome, and KDE desktop installed.
I go back into my software installation on the physical machine, and under view by patterns there is this:
under "base technologies" it has
- base system
- app armor
- 32 bit runtime environment
- XEN virtualization host (non embedded)
- KVM virtualization host (non embedded)
under "primary functions" it has
- File Server (nfs, samba, that sort of thing)
- Infiniband
- DHCP & DNS Server
- Directory Server (LDAP)
- KVM Virtual machine host server **
- XEN Virtual machine host server **
is it here in my original physical system that i need to install the KVM vm host server ** ?
i'm still confused why during the install from dvd i'm presented with those 4 options that i described above, and when/how you would use those.
and under the base technologies, what then is the non-embedded hosts?
It's really not as complicated as you're making it out to be.
KVM, XEN, VMWare, Virtualbox are just programs that are used to run VMs. Pick one, it doesn't matter which (they each have their advantages and disadvantages), install it on your host, and use it to install a VM.
The SLES installation options are just different software configurations that are tailored to different applications. If your host OS is ONLY going to run VMs and do NOTHING else, then it has no need for a desktop environment or X. That's what the "XEN/KVM Virtualization Host" options are for. If you want to use your system to do normal work in addition to hosting VMs, then just do the normal installation and then install XEN/KVM/VMWare/Virtualbox on it.
I don't know what the "non embedded" note means, but I have no experience with XEN or KVM.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.