[Users] from irc

[Bob Doolittle]

Thanks, this answers a lot of questions Einav.

Let's be careful about terminology, however. "sealing" in this context 
is the process of un-sysconfig'ing (aka depersonalizing) the machine to 
make it generic before cloning/copying. After unconfiguring, the next 
time the system boots up it goes through sysconfig again. For Windows 
this involves the 'sysprep' command. For Linux it involves the 
/.unconfigure file. I'm still trying to understand the value of sealing 
in the VDI context, and what adverse effects would be if we didn't take 
this step.

So in this context the term "sealing" is quite different from 
snapshot/restore.

I'll respond more in the next mail (to Itamar).

Thanks again,
    Bob

On 11/15/2013 09:28 AM, Einav Cohen wrote:
> Hi Bob,
>
>> ----- Original Message -----
>> From: "Bob Doolittle" <bob at doolittle.us.com>
>> Sent: Friday, November 15, 2013 8:41:47 AM
>>
>> 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.
>>
>> 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.
> unless something dramatic has changed lately in this feature's
> implementation: AFAIK, the Pool doesn't clone VMs from a Template on
> demand; the Pool VMs are provisioned in advance (upon Pool creation),
> which allows, of course, the admin to access them, launch them, prepare
> them for usage, etc, as Itamar explained.
>
>> 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?
> there is a difference between the way that an admin runs the VM and the
> way that a user runs the VM (by allocating himself a VM from the pool
> via his user portal): The admin typically runs the VM like any "regular"
> VM, i.e., not in a "stateless" mode, which ensures that all changes
> done on the guest will be persisted for the VMs next run.
> This is necessary for the initial OS installation of the VM, for example,
> initial configuration, application installation, etc.
>
> When the user runs the VM (again - by allocating himself a VM from the
> pool via the user portal), the VM actually runs in a stateless mode:
> right before the VM is run, a snapshot is taken from it; once the VM is
> being shutdown/returned to the pool, the VM reverts itself to that
> snapshot, clearing all changes done in this run (but not changes that
> the admin did in the initial run! those are "sealed" within the VM),
> leaving the VM and ready for the next allocation.
>
>> Thanks,
>>       Bob
>>
>> P.S. I note the behavior of Fedora vs RHEL 6 is quite different in this
>> regard. If you follow the "sealing" process on the Quick Start page for
>> Fedora it seems to have no visible effect, but on RHEL 6 it puts you
>> through a re-personalization dialog which is rather extensive (and
>> again, not really suitable for VDI use).
>> _______________________________________________
>> Users mailing list
>> Users at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/users
>>
>>
>>