[Users] avoiding sysprep per boot with pooled vms (was from irc)

[Bob Doolittle]

On 11/15/2013 08:51 AM, Itamar Heim wrote:
> On 11/15/2013 08:41 AM, Bob Doolittle wrote:
>> Hi,
>>
>> I had a question on IRC regarding sysprep/sealing of Windows VMs and use
>> in Pools. Basically, if you follow the Quick Start Guide, it says to
>> seal the VM and shut it down before making the Template.
>>
>> My problem with this is that when you start a VM from the Pool, it takes
>> forever to unseal - i.e. to repersonalize itself. That's a bad
>> experience from a VDI perspective - you want the user to get a desktop
>> they can start using ASAP.
>
> that's why Pools have "auto start VMs" - you can define you want the 
> pool to always keep X VMs up and running and ready for the users.

Yes I can see this becomes more important when there's such a long 
startup time due to unsealing.

>>
>> Itamar responded to me directly via e-mail:
>>
>>  > bobdrad: on your question of windows VMs from pool - you can start
>>  > them once with an admin for the sysprep to happen, then shut them 
>> down.
>>  > admin launch of VMs doesn't create a stateless snapshot and
>>  > manipulates the VM itself.
>>
>> This raises some questions. I'd love to understand this better.
>>
>> He's asked me to cross this conversation onto the Users list now.
>>
>> 1. My understanding is that a Pool clones VMs on demand from a template.
>> So how does the admin "launch" the template? I thought the only way to
>> exercise a pool is from the User Portal. Is it sufficient to do that as
>> Admin? I thought the persistence only came when launching a VM from the
>> Admin Portal.
>
> The VM is created as part of pool creation.
> an admin can start the VM from webadmin as well.

OK so there seems to be a serious scalability issue here. It is not 
unusual for a large VDI deployment to utilize hundreds of VMs. From what 
you're telling me, if we don't want users to experience the unsealing 
delay (which takes several minutes) every time, an admin would have to 
start all of those VMs after creating the Pool, and then cleanly shut 
them all down again once they'd all finished their unsealing process. 
Either that, or set them all to auto-start, but this puts unnecessary 
load on the host since they have to unseal after snapshot-revert every 
time they come up.

There is perhaps an attractive feature that might help here. At the 
moment you can set an absolute number of "auto-start" VMs for the pool. 
I think what's needed is something more like an HA "standby" model which 
is applied to hosts and disks - you would like a certain number of 
not-yet-allocated, auto-started ("waiting-auto-started"?) VMs to be in 
the pool at all times (unless of course the pool is exhausted). In other 
words, say you have a large pool of VMs, and you set a 
waiting-auto-started count to 10. If 20 users connect to VMs, 10 more 
would be started up and waiting in the pool.  You could shut down/return 
any extras as VMs are returned to the pool (optionally?). The goal here 
is to eat the startup delays in advance to have ready-to-use VMs 
available for users at all times, without needing to start them all 
(which would consume excessive host resources). I think this would be 
more valuable than a fixed count, although maybe that's helpful in some 
use cases.

> unless admin will flag the runvm action with stateless, it will change 
> the VM.
> i.e., the admin will be starting the VMs created in the pool, not the 
> tempalte itself.

Excellent - so that's what the "stateless" radiobox is for. :)

> caveat: for windows VMs, if the VM is doing the sysprep by the admin 
> (persistently), you need to change the domain policy to avoid the 
> computer account password change (will cause the VM to lose 
> connectivty to the domain after 90 days).
>
> hence the auto starting VMs is better for some use cases.
>
>>
>> 2. My understanding of "sealing" a system is that this depersonalizes it
>> - e.g. removes hostname, prepares network for reinitialization, etc. And
>> that the next time the system boots up it re-personalizes. So if one
>> were to restart it, even as admin, this would reverse the sealing
>> process, which would seem to make sealing in the first place pointless.
>>
>> What am I missing? At the moment I don't see the point of sealing a VM
>> before putting it into the Pool (assuming you're using DHCP, anyway).
>> What happens if you don't?
>
> its considered microsoft best practice. there is also a security 
> concern if the VMs are not part of a domain, since they would have the 
> same SID.
>
> other caveats may apply, but may be good enough for your use case.

I see that makes sense. I was also wondering from a security 
perspective. I know that when Linux first boots up it creates 
public/private RSA keys, presumably for things like filesystem 
encryption. So it would be bad to clone a VM that had already generated 
a (single) private key. I wouldn't be surprised if Windows does 
something similar at first OS boot.

-Bob