Daylight Savings - The RIGHT way

I have seen this

https://portal.nutanix.com/#/page/kbs/details?targetId=kA03200000098c9CAA

But - still i need to do this on every single VM??

The preferred way is this
https://portal.nutanix.com/#/page/kbs/details?targetId=kA03200000098J2CAI

Acording to the KB

This is REALLY a bad solution.. 😞

Checking with engineering now, standby

AHV (more specifically the virtual BIOS) will pass UTC to the guest OS. Any reason you cannot use NTP + Windows TZ setting?

If those guests are in a domain, the clock is synced with the AD server automatically. Adding alternate or external NTP and TZ is just a matter of group policy. Windows OS (and most others) run on UTC and just use TZ for display (human consumption) purposes.

Waiting on engineering, but I will say, theres a long story to why it works on VMW/etc.

As far as I recall, this is mainly because they are asking you to predefine the OS type when you create the VM (I'm sure you've seen that setting).

the Hypervisor then is programmed by the control plane (i.e vCenter) to know that said VM is a Windows VM, so it sets these things up in the vBIOS for you.

Since we treat all VM's the same here, there is not the same hinting mechanism

Heh, our responses crossed in flight, 

In short, yes, we're huge UTC fans here at Nutanix, but I think we could make this a bit easier. I'll see what we can do

I've filed an internal engineering ticket to get some clarification here, waiting on response for that.

In the mean time, procede down the KB documented routes.

The problem is that the recomended KB article is not working in Winter time - its 1 hour wrong in windows now - after the wintertime change..

But the Timezone option on the VM is working - as expected - only issue is we need to set it every time we create a new windows VM - in Command line :(

Not a good option..

Ah! ok, I didn't understand you the first time. Please submit a support ticket for the KB not working in Winter time. I believe you're a dell customer if I recall correctly, so submit the ticket to dell and have them escalate it up to us.

As a parallel track, I've got the aforementioned engineering ticket going, but those generally have a slower SLA than customer support tickets, so please do submit a ticket yourself

Case number 00091367
This case is created referencing the Dell Case number - created by dell it should be escalated from dell as well.

Quick point as you may have already seen, the case flow needs to be to Dell first, then they will escalate up through us and file their own tickets on your behalf. Dell is always the first point of contact for anything XC

Quick question, did you do BOTH the registry tweak, and the ACLI command?

It seems like its working if i remove the registry key and set the timezone on AHV acli..

But as stated in the KB this is not preferred - but why? Know its stupid and wierd i have to do it command line - but still i dont have to change the Client VM registry .. what is worst?

Ah, ok, good.

I think the right expression here is "Pick your poison", one or the other, not sure if that translates right.

On one hand, you could set this via registry in a template, and be done with it for good, or the other you can set it up via ACLI on a per VM basis. I agree that both options are less than ideal, so we'll take this feedback and see what we can do to make this better.

Well the registry in the template is NOT working.. :(

it worked in Summer Time but if i have a clean VM and set the Registry and powercycle the time is 1 hour wrong - i just went with that solution since the KB mentioned this as the preferred solution.

But its simply not working as expected - we have teste on another solution as well - on a Nutanix hardware cluster exact same issue..

Last thing I'll say for now, while we sort this out on our side, is that this is the common stance in cloud providers like AWS: http://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/windows-set-time.html, which would also make you apply these registry tweaks.

Ok, understood about registry not working. Drill that down with support so we can get to the bottom of the issue.

Do you know how to remove the hw_clock defined on the VM from ACLI - now im uanble to remove the value to test the exact scenarie.. 😞

do that ACLI command with timezone=utc

Also worth while to note that these changes are only applied on full power cycle of the VM, as you may have seen before. Just wanted to clarify. shutdown > cold boot will do the change right

Correct not on reboot

It does not remove the option from the VM in vm.get

So there must be some kind of default - maybe utc as you say but if i want to be 100% sure :-)

TimeTest {config {annotation: ""disk_list {addr {bus: "ide"index: 0}cdrom: Trueempty: True}disk_list {addr {bus: "scsi"index: 0}container_id: 1540container_uuid: "ad549ea8-91e8-494a-9c5c-22ca29af9a77"source_vmdisk_uuid: "4c416525-9e17-47de-a00f-d9474c243c76"vmdisk_size: 64424509440vmdisk_uuid: "8741af6a-7948-4ed3-be7d-6d840ff02e04"}hwclock_timezone: "UTC"max_hotplug_memory_mb: 262144memory_mb: 8192name: "TimeTest"num_cores_per_vcpu: 1num_vcpus: 2}host_name: "NTNX-J2FKF62-A.mgnt.local"host_uuid: "976d666e-0661-422f-8d55-1c299bee8299"logical_timestamp: 6state: "kOn"uuid: "1fe53095-9b50-475a-af66-7c6d13819884"}

Another VM - where it have not been set

000 XD75WK02 {config {annotation: "Defekt - virker ikke med SFB"disk_list {addr {bus: "ide"index: 0}cdrom: Trueempty: True}disk_list {addr {bus: "scsi"index: 0}container_id: 1646container_uuid: "36f058d3-5d55-4ea7-9059-bf8ba5bbf2b1"source_vmdisk_uuid: "e4a83ff6-05e7-41a5-9e63-addd51c08a97"vmdisk_size: 107374182400vmdisk_uuid: "cd5ed662-8f60-40c2-b460-858cd0c96dd0"}max_hotplug_memory_mb: 262144memory_mb: 8192name: "000 XD75WK02"nic_list {mac_addr: "52:54:00:66:0e:9b"network_name: "000_ZIT_Internt"network_uuid: "868789d7-71dd-46f7-9877-1625a8f0a194"}num_cores_per_vcpu: 2num_vcpus: 2}host_name: "NTNX-J2FKQ92-A.mgnt.local"host_uuid: "a6ede015-34d6-4cda-93fa-bd9f875e14e1"logical_timestamp: 12state: "kOn"uuid: "d7bfc547-d0d7-43b6-b843-c351c0e70bd4"}

Yes, UTC is the default, I dont think theres a way (off hand) to null that out completely, but you've set it back to the default, so the behavior between those two configs SHOULD be the same.

Hey just checking in, were you able to make any progress here?