Hi, I'm in the process of doing an upgrade to 1.0.1 and then doing a 1.0.1 install/configure from scratch. Your question about storage is a little off. First of with 1.0, you only needed to go into config mode (factory-default) if you were going to change something fundamental service wise in the control domain. For example, if you were going to create a new VDS or VSW, or change the number of VCPUs, MAUs, or mem for the control domain. It didn't apply to vnets, vds-devs, vdisks, etc. So you could dynamically add SAN LUNs or create virtual disk images on the fly, turn them into vds-devs and add them as vdisks to guest domains. The only caveat is that if the guest domain was already up, you have to reboot the guest domain for it to see the changes, unless you were only adding/removing VCPU's.
>From what Eric has stated, it would appear that the requirement to go into >factory-default mode has been removed, so you can change fundamental resources >and services of the control domain itself. However, it still requires a reboot >of the control domain to take affect if I understand correctly. The big >feature in LDoms 1.0.1 is the ability to queue up I/O requests from guest >domains so that a service/io domain, such as the primary domain, can be >rebooted. Obviously, if it does not come up in time, I/O operations would >time-out and you'd have a lot of interesting issues to deal with. Hopefully I got that right. I'll have some blog posts this weekend about 1.0.1. *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Octave J. Orgeron Solaris Systems Engineer http://www.opensolaris.org/os/community/sysadmin/ http://unixconsole.blogspot.com unixconsole at yahoo.com *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* ----- Original Message ---- From: Dan Gubber <[email protected]> To: ldoms-discuss at opensolaris.org Sent: Wednesday, October 31, 2007 10:54:43 AM Subject: Re: [ldoms-discuss] LDOM Configurations 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.... 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. 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. Please let me know Dan -- This message was posted from opensolaris.org _______________________________________________ ldoms-discuss mailing list ldoms-discuss at opensolaris.org http://mail.opensolaris.org/mailman/listinfo/ldoms-discuss __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
