Hi Dan, Dan Gubber wrote: > Seems the thread is getting split... but > > Sharakan - you indicate in one of your posts that it is possible to > "reconfigure" the control domain after it has booted, as opposed to having to > reboot to the factory-default config, reconfigure the control domain, then > reboot to the control domain under the new V1.0.1. This is better, but I > hope it doesn't end there. > > Here's what I'm getting at...... > > Let's assume I have a physical server such as a T2000 or a T5220 and I've > deployed the control domain with 4VCPU and 4g of memory. Also, then from this > control domain I've created a single guest domain, 8VCPU w/ 8G of mem, > leaving the rest of the physical server "un-partitioned" at this time. This > would leave me with 20VCPU and 20G of physical memory available for new > LDOM's ( if using a T2000 ). > > Let's also assume for the sake of this argument, that I further partitioned > the single guest domain using Solaris Containers. > > In order for me to create / activate a new guest domain, I have to > reconfigure the control domain with new disk space for a new guest domain, > ie, present new LUN's from the SAN.... >
Once you have configured your domain to have a vDisk service (using ldm add-vds) there is no need to reboot the control/service domain to add more disks/guests (this applies to both v1.0 and v1.0.1). Adding disks is not a reconfiguration (it's adding the services that is the reconfiguration and that's a much more uncommon operation - usually you would set it up once) Below is a overview of the steps involved adding a new guest (and adding the disk it would use). ldm add-vdsdev <disk from SAN> vol2 at primary-vds0 ldm create newdomain ldm add-vdisk vdisk2 vol2 at primary-vds0 newdomain ..... add other resource ..... ldm bind newdomain ldm start newdomain connect to the console of newdomain... > Please correct me if I'm wrong, but based on what your indicating, in order > for that space to be useable in a virtual sense by the new guest domain I am > attempting to deploy, I would have to reboot the control domain. Also, I > would not be able to reboot the control domain without taking offline the > currently deployed guest domain, ie, that and any containers that are > deployed on it. > With LDoms 1.0.1, you can reboot the control domain while the guests are active (although as I mentioned above, you don't need to in this case). > The other option is to be able to look into the future and pre-determine all > of my resource use requirements prior to deploying the physical server, > pre-configure it entirely, and deploy the control domain based on a guess. > > If this issue doesn't come up regarding disk space ( I should be able to > configure new disk space, present it to the control domain, create a new > guest domain, present that new LUN to the new guest domain, install the guest > domain and run without ever having to reboot the control domain ), are there > particular services, using the model I mentioned, that you would HAVE to > reboot the control domain ? > > If that's the intention, I don't believe this is good enough. If it is an > intermediate step, it appears that there is still quite a bit of work to do > to make LDOM's what they really need to be. HTH -- Liam
