Hi all - we have HUGE problems in Denmark with setting the correct Daylight savings in AHV
A clock / time settings apprently not just an option in AHV..
We found that we neede to set this in Windows guests to get the clock correct - otherwise it was 2 hours wrong
reg add "HKEY_LOCAL_MACHINESystemCurrentControlSetControlTimeZoneInformation" /v RealTimeIsUniversal /d 1 /t REG_DWORD /f
Now when we have shifted to winter time CET instead of CEST and we shutdown the VM's the clock is 1 hour wrong!!
What is the 100% correct way to handle time on AHV?
I have never had issues on VMware, HyperV or Xen with this basic stuff.. 😞 If anyone could lead me to a KB or something about this issue?
Page 1 / 1
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.. 😞
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.
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
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
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.
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..
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
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.
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?
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.
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..
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"}
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?
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.