[CentOS] error creating Centos 5.1x32 dum_Uinstance on CentOS5.1x64

Sat Mar 1 19:23:53 UTC 2008

Ross S. W. Walker wrote:
> Rudi Ahlers wrote:
>   
>> Ross S. W. Walker wrote: 
>>     
>>> That shouldn't be, the list acts like any other CentOS list, maybe
>>> you entered your email address incorrectly, got spam filtered, or
>>> is just temporarily broken, but it should send you an email upon
>>> subscribing to confirm your subscription.
>>>   
>>>       
>> Really? Maybe I subscribed to the wrong list then, but this 
>> is the reply 
>> I got:
>>
>> Your mail to 'CentOS-virt' with the subject
>>
>>     subscribe centos-virt
>>
>> Is being held until the list moderator can review it for approval.
>>
>> The reason it is being held:
>>
>>     Message may contain administrivia
>>     
>
> Try subscribing through the mailman web site:
>
> http://lists.centos.org/mailman/listinfo
>
>   
Odd, my subscription did go though on the first email, as I got a 
message saying I'm already subscribed. I'll post there as well, let's 
see what happens :)
>
>   
>>> Did you verify that selinux is indeed disabled by looking in
>>> /etc/selinux/config that the line SELINUX=disabled is in there?
>>>
>>>   
>>>       
>> Yep:
>>
>> # This file controls the state of SELinux on the system.
>> # SELINUX= can take one of these three values:
>> #       enforcing - SELinux security policy is enforced.
>> #       permissive - SELinux prints warnings instead of enforcing.
>> #       disabled - SELinux is fully disabled.
>> SELINUX=disabled
>> # SELINUXTYPE= type of policy in use. Possible values are:
>> #       targeted - Only targeted network daemons are protected.
>> #       strict - Full SELinux protection.
>> SELINUXTYPE=targeted
>>     
>
> Good, just some users use setenforce 0 and think that's it done
> and then reboot and wonder why things are still not working
> properly.
>
>   
>>> What was the actual contents of your domU's config file?
>>>
>>>   
>>>       
>> This is what I changed:
>>
>> # Dom0 will balloon out when needed to free memory for domU.
>> # dom0-min-mem is the lowest memory level (in MB) dom0 will 
>> get down to.
>> # If dom0-min-mem=0, dom0 will never balloon out.
>> (dom0-min-mem 512)
>>
>> It was:
>> (dom0-min-mem 256)
>>     
>
> Misunderstanding, I was hoping to see the config file of the
> domU you were trying to create.
>   
You meant this?

[root at gimbli ~]# more /etc/xen/vm03
name = "vm03"
uuid = "cc3b0b01-7894-4ac2-06e6-a1a1307939fc"
maxmem = 512
memory = 512
vcpus = 1
bootloader = "/usr/bin/pygrub"
on_poweroff = "destroy"
on_reboot = "restart"
on_crash = "restart"
vfb = [  ]
disk = [ "tap:aio:/home/vm/vm03.img,xvda,w" ]
vif = [ "mac=00:16:3e:0a:13:9d,bridge=xenbr0" ]

>   
>>> Also is this a workstation with Xen domU's for testing/development
>>> or a full blown Xen server for running production VMs?
>>>
>>> -Ross
>>>   
>>>       
>> This will be a full blown Xen server for production purposes. It will 
>> run max 8 Xen guests with cPanel on each one.
>>     
>
> In that case if you don't want to shell out the $ for Xen Enterprise
> I would do these steps for setting up a Xen server:
>
> - for each server, minimal install, no X to reduce any possible dom0
> issues, and to allow you to minimize dom0 memory usage, you can then
> run in 256MB with no X windows!
>
> - use the Xen 3.2 packages off of xen.org, compiled 64-bit, compile on
> separate 64-bit platform as the compilation will pull in a lot of other
> development packages and X. These packages use the Xen kernel from
> CentOS for the kernel image, and that package comes with the 3.1 Xen
> image so you'll need to edit the grub.conf to make sure the Xen 3.2
> image is used instead of the 3.1 image every time you upgrade the kernel.
> These packages provide the latest features and fixes as well as the more
> capable management tools and API which will become a necessity when you
> manage from the command line and/or have more then 1 server which
> eventually you will for scalability, redundancy, etc.
>
> - Start seriously thinking about implementing an iSCSI SAN, your
> storage requirements will balloon crazy until your virtualization
> environment stabilizes, and SANs allows for better storage
> utilization, scalability and also allows for VM migration from one host
> to another and are a bitch to migrate to after the fact.
>
> - Build your Xen config files by hand, it's the only way to assure
> they are setup properly and the way you want.
>
> Since a Xen environment will be sensitive to change, maybe not as
> much as a LAMP environment, but still probably second to, you may
> want to manage your Xen build yourself, at least for the servers,
> as Redhat's Xen implementation is still evolving.
>
> I would use Redhat's Xen environments once they have a pure Xen 3.2
> build, as their current Frankenstein environment is really aimed
> at workstation deployments, especially their hoaky X tool.
>
> -Ross
>
> ______________________________________________________________________
>   

Ross, you're talking about "scary" new stuff which I haven't even though 
about.
- What I'd like to accomplish, is to have a few dedicated servers (Our 
company is the hosting company, and this is the first time we go into 
virtualization ), each running up to say 10 VPS / VM's (which is much 
cheaper than a full blown dedi to the client)
None of the servers have X (no point to it), and we use a very, very 
minimal install (I don't even have FTP running, since cPanel will 
provide this). The VPS's will either have 256MB (cPanel minimum) / 512 / 
786 / 1GB RAM - Obviously if more RAM is desired per VPS, less will be 
run on 1 server, or the server will have more RAM & CPU's HDD space will 
also either be 10 / 20 / 40 / 60 GB per VPS. The VPS' itself will only 
run cPanel, no X - a server doesn't need X for anything. So, 10 VPS with 
512MB each = 12GB needed on host server. Many Xeon mobo's can take upto 
32GB RAM.

- I'm a bit sceptic about using Xen 3.2 off the Xen site, as I don't 
know how well it'll perform on CentOS and I believe that if CentOS 
hasn't included in their repositories yet, then there must be a good 
reason. I'll test it on a test server though to see what happens. I 
think the other problem I have, is that these servers are deployed from 
the standard CentOS 5.1 CD & a kickstart file with only the necessary 
software & nothing more. Having to compile software on another machine 
isn't fun for me.

- I just want to understand this better. If I run a 64bit host, and want 
to install any other guest (preferably 32bit), then I need to use the 
"fully virtualized guest" and not the para-virtualized  option, right?

- I like where you're heading with the suggestion of an iSCSI SAN, but 
that's totally new to me as well, and not in my budget right now. Maybe 
later on when this whole project takes off as I hope for it to take off. 
But, since you mention it, do you then setup the server with a base OS, 
and mount the iSCSI SAN as added storage? And then all the VM's get's 
stored on the SAN, instead of the server's HDD's? And how well will such 
a setup perform if I have say 5 / 10 servers connected to it? I guess 
the SAN will then at least need 4 Gigabit NIC's, as the hubs in the DC 
are only 100Mbit hubs. For a startup SAN, what would you suggest? I 
guess a PC / server based SAN (in other words, I take a Xeon mobo with 
plenty of HDD ports and put plenty HDD's on it) isn't really an option?

For now I'm going to manage the Xen stuff myself, I don't have anyone 
capable of doing this kind of work yet.

-- 

Kind Regards
Rudi Ahlers
CEO, SoftDux

Web:   http://www.SoftDux.com
Check out my technical blog, http://blog.softdux.com for Linux or other technical stuff, or visit http://www.WebHostingTalk.co.za for Web Hosting stugg