Jim,

Thanks a lot for your confirmation.

Could you also please explain if the issue can be ever fixed, if it's possible to make some patch to fix it?

Is it libvirt-specific bug or Libvirt development team rely on some other developers of libxl code...etc?

I'm asking because XL tools works fine and I wonder if XL uses the same libxl libraries , doesn't it?

Lastly is the issue is going be fixed in near time? Can you answer my questions and ask for some patch for

enhancement request or I should better send a separate email to development team ("libvir-list@redhat.com") ?

Thanks a lot in advance for your answers...

On Fri, Feb 16, 2018 at 8:37 PM, Jim Fehlig <jfehlig@suse.com> wrote:

On 02/16/2018 08:37 AM, Volo M. wrote:

Hello techs,

We used XL toolkit for Xen hypervisor for starting Windows hvm VMs and the option rtc_timeoffset worked perfectly with XL. It helped us to set correct Timezone time/offset for Windows HVM VMs from inside virtual_machine xen config.

For example:
Below option WORKS perfectly with XL toolkit.
[root@hw12xen ~]# cat goillltawdlssq.xl.cfg | grep offset
rtc_timeoffset = "7200" # +2 hours to UTC time (or +/-3600=+/-1 hour to UTC time)
[root@hw12xen ~]#

Now we try to migrate all the Windows hvm VMs to using Libvirt and Xen 4.6.6 (or 4.4).
But as we see it's impossible to make VMs using correct time/offset set in XML config like below:

below Libvirt option DOESN'T WORK as we expect...
[root@hw12xen ~]# cat goillltawdlssq.var.xml | grep offset
<clock offset='variable' adjustment='7200' />
[root@hw12xen ~]#

Can you please explain if there's something we're doing wrong way or it's just a bug like described here:
https://bugzilla.redhat.com/show_bug.cgi?id=1212191 ?

No, you're not doing anything wrong. And yes, you've hit that bug, although I'd prefer to call it an enhancement request. Xen's rtc_timeoffset setting is currently not supported by the libvirt libxl driver.

Regards,
Jim