Hi Richard,
Could you please help here .
Thanks
Teja Konapalli
From: Teja Konapalli
Sent: Sunday, September 24, 2023 10:27 PM
To: 'Richard W.M. Jones'
Cc: 'libguestfs@redhat.com' ; Raja Ram Sharma
; Divyanshu Kumar
Subject: RE: Libguestfs desired version installation
Hi Richard,
If
I didn't set the -rtc flag in the normal (UTC) case as that is the
default.
---
output/output_qemu.ml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/output/output_qemu.ml b/output/output_qemu.ml
index 57b1e58da2..a9d7b37071 100644
--- a/output/output_qemu.ml
+++ b/output/output_qemu.ml
@@
This change simply adds the flag to guestcaps, and sets it to always
true, so there is no change to the output.
---
lib/types.mli | 5 +
convert/convert_linux.ml | 1 +
convert/convert_windows.ml | 1 +
lib/types.ml | 3 +++
4 files changed, 10 insertions(+)
diff
---
output/create_libvirt_xml.ml | 10 --
tests/test-v2v-i-ova.xml | 1 +
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/output/create_libvirt_xml.ml b/output/create_libvirt_xml.ml
index 964acd25fd..f97272ca31 100644
--- a/output/create_libvirt_xml.ml
+++
---
output/create_kubevirt_yaml.ml | 5 +
1 file changed, 5 insertions(+)
diff --git a/output/create_kubevirt_yaml.ml b/output/create_kubevirt_yaml.ml
index 689555e4dc..b96c742832 100644
--- a/output/create_kubevirt_yaml.ml
+++ b/output/create_kubevirt_yaml.ml
@@ -54,6 +54,11 @@ let
On Mon, Sep 25, 2023 at 05:58:00PM +0200, Laszlo Ersek wrote:
> On 9/25/23 16:04, Richard W.M. Jones wrote:
> > Read HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation key
> > "RealTimeIsUniversal" to see if the Windows guest is expecting BIOS
> > set to localtime (not present) or UTC
On Mon, Sep 25, 2023 at 05:47:26PM +0200, Laszlo Ersek wrote:
> On 9/25/23 16:04, Richard W.M. Jones wrote:
> > ---
> > output/create_libvirt_xml.ml | 10 --
> > tests/test-v2v-i-ova.xml | 1 +
> > 2 files changed, 9 insertions(+), 2 deletions(-)
> >
> > diff --git
[Alice: See patch 2]
[This patch is a bit rough, it could do with better commit messages
and some tests. Please test it to see if it solves the Windows
conversion issue described in the thread below.]
We currently do not set any field in guest output. Most
Windows guests expect the BIOS to be
Read HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation key
"RealTimeIsUniversal" to see if the Windows guest is expecting BIOS
set to localtime (not present) or UTC (present and set to 1).
See: https://wiki.archlinux.org/title/System_time#UTC_in_Microsoft_Windows
See:
On 9/25/23 16:04, Richard W.M. Jones wrote:
> ---
> output/create_libvirt_xml.ml | 10 --
> tests/test-v2v-i-ova.xml | 1 +
> 2 files changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/output/create_libvirt_xml.ml b/output/create_libvirt_xml.ml
> index 964acd25fd..f97272ca31
Almost every Linux guest expects the motherboard Real Time Clock (RTC)
to be set to UTC and they adjust the time displayed based on their
timezone (which may be different for each user).
Most Windows guests expect the RTC to be set to the local time.
Windows can be configured to use a UTC clock.
The main changes are:
- BIOS -> RTC passim
- Split out the minor refactoring patch
- Enhanced commit messages
- Add Laszlo's R-b tag
Rich.
___
Libguestfs mailing list
Libguestfs@redhat.com
https://listman.redhat.com/mailman/listinfo/libguestfs
I didn't set the -rtc flag in the normal (UTC) case as that is the
default.
Reviewed-by: Laszlo Ersek
---
output/output_qemu.ml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/output/output_qemu.ml b/output/output_qemu.ml
index 57b1e58da2..1a5f7f7147 100644
--- a/output/output_qemu.ml
+++
Read HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation key
"RealTimeIsUniversal" to see if the Windows guest is expecting RTC
set to localtime (not present) or UTC (present and set to 1).
See: https://wiki.archlinux.org/title/System_time#UTC_in_Microsoft_Windows
See:
Reviewed-by: Laszlo Ersek
---
output/create_libvirt_xml.ml | 6 ++
tests/test-v2v-i-ova.xml | 1 +
2 files changed, 7 insertions(+)
diff --git a/output/create_libvirt_xml.ml b/output/create_libvirt_xml.ml
index 12586fde17..30119d1357 100644
--- a/output/create_libvirt_xml.ml
+++
Minor refactoring of how section is generated in XML output.
There is no change in the output.
Reviewed-by: Laszlo Ersek
---
output/create_libvirt_xml.ml | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/output/create_libvirt_xml.ml b/output/create_libvirt_xml.ml
index
Reviewed-by: Laszlo Ersek
---
output/create_kubevirt_yaml.ml | 5 +
1 file changed, 5 insertions(+)
diff --git a/output/create_kubevirt_yaml.ml b/output/create_kubevirt_yaml.ml
index 689555e4dc..e3a3f422df 100644
--- a/output/create_kubevirt_yaml.ml
+++ b/output/create_kubevirt_yaml.ml
@@
On Mon, Sep 25, 2023 at 04:26:59PM +0200, Alice Frosi wrote:
> Hi Rich,
>
> On Mon, Sep 25, 2023 at 4:10 PM Richard W.M. Jones wrote:
>
> [Alice: See patch 2]
>
>
> I'm not 100% sure about the source of this work. However, we had in
> KubeVirt people interested in using localtime with
Hi Rich,
On Mon, Sep 25, 2023 at 4:10 PM Richard W.M. Jones
wrote:
> [Alice: See patch 2]
>
I'm not 100% sure about the source of this work. However, we had in
KubeVirt people interested in using localtime with Windows [1]. Yes, I see
that you pointed to that PR in patch 2. The problem with
On 9/25/23 17:48, Laszlo Ersek wrote:
> On 9/25/23 16:04, Richard W.M. Jones wrote:
>> [Alice: See patch 2]
>>
>> [This patch is a bit rough, it could do with better commit messages
>> and some tests. Please test it to see if it solves the Windows
>> conversion issue described in the thread
On 9/25/23 16:04, Richard W.M. Jones wrote:
> [Alice: See patch 2]
>
> [This patch is a bit rough, it could do with better commit messages
> and some tests. Please test it to see if it solves the Windows
> conversion issue described in the thread below.]
>
> We currently do not set any field
On Mon, Sep 25, 2023 at 10:16:10AM +0100, Richard W.M. Jones wrote:
> On Mon, Sep 25, 2023 at 09:09:32AM +, Teja Konapalli wrote:
> > Hi Richard,
> >
> > Yes, you are correct my ask is without upgrading OS version(from 8.2
> > to 9.0) is it possible to upgrade libguestfs alone to different
> >
Hi Richard/Eric,
I wanted to take a moment to express my sincere gratitude for your invaluable
contributions to "libguestfs" project.
And assistance with current issue "mount_local: unknown option 684826080".
The issue has been successfully resolved and our project is back on track.
Just to
On Mon, Sep 25, 2023 at 04:26:59PM +0200, Alice Frosi wrote:
> Hi Rich,
>
> On Mon, Sep 25, 2023 at 4:10 PM Richard W.M. Jones
> wrote:
>
> > [Alice: See patch 2]
> >
>
> I'm not 100% sure about the source of this work. However, we had in
> KubeVirt people interested in using localtime with
On 9/25/23 16:04, Richard W.M. Jones wrote:
> Read HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation key
> "RealTimeIsUniversal" to see if the Windows guest is expecting BIOS
> set to localtime (not present) or UTC (present and set to 1).
>
> See:
On Mon, Sep 25, 2023 at 05:49:18PM +0200, Laszlo Ersek wrote:
> On 9/25/23 17:48, Laszlo Ersek wrote:
> > On 9/25/23 16:04, Richard W.M. Jones wrote:
> >> [Alice: See patch 2]
> >>
> >> [This patch is a bit rough, it could do with better commit messages
> >> and some tests. Please test it to see
Time to start supporting clients that request extended headers. Now
we can finally reach the code added across several previous patches.
Even though the NBD spec has been altered to allow us to accept
NBD_CMD_READ larger than the max payload size (provided our response
is a hole or broken up
The NBD spec states that if the client negotiates extended headers,
the server must avoid NBD_REPLY_TYPE_BLOCK_STATUS and instead use
NBD_REPLY_TYPE_BLOCK_STATUS_EXT which supports 64-bit lengths, even if
the reply does not need more than 32 bits. As of this patch,
client->mode is still never
Update the client code to be able to send an extended request, and
parse an extended header from the server. Note that since we reject
any structured reply with a too-large payload, we can always normalize
a valid header back into the compact form, so that the caller need not
deal with two
All the pieces are in place for a client to finally request extended
headers. Note that we must not request extended headers when qemu-nbd
is used to connect to the kernel module (as nbd.ko does not expect
them, but expects us to do the negotiation in userspace before handing
the socket over to
Once extended mode is enabled, we need to accept 64-bit status replies
(even for replies that don't exceed a 32-bit length). It is easier to
normalize narrow replies into wide format so that the rest of our code
only has to handle one width. Although a server is non-compliant if
it sends a
Peform several minor refactorings of how the list of negotiated meta
contexts is managed, to make upcoming patches easier: Promote the
internal type NBDExportMetaContexts to the public opaque type
NBDMetaContexts, and mark exp const. Use a shorter member name in
NBDClient. Hoist calls to
The next commit will add support for the optional extension
NBD_CMD_FLAG_PAYLOAD during NBD_CMD_BLOCK_STATUS, where the client can
request that the server only return a subset of negotiated contexts,
rather than all contexts. To make that task easier, this patch
populates the list of contexts to
Allow a client to request a subset of negotiated meta contexts. For
example, a client may ask to use a single connection to learn about
both block status and dirty bitmaps, but where the dirty bitmap
queries only need to be performed on a subset of the disk; forcing the
server to compute that
v6 was here:
https://lists.gnu.org/archive/html/qemu-devel/2023-08/msg05231.html
Since then:
- patches v6 1-5 included in pull request
- patch v6 6 logic improved, now v7 patch 1
- rebased to master
Still needing review:
- patch 1,6,7,11,12
Eric Blake (12):
nbd/server: Support a request
Upcoming additions to support NBD 64-bit effect lengths allow for the
possibility to distinguish between payload length (capped at 32M) and
effect length (64 bits, although we generally assume 63 bits because
of off_t limitations). Without that extension, only the NBD_CMD_WRITE
request has a
Although extended mode is not yet enabled, once we do turn it on, we
need to accept extended requests for all messages. Previous patches
have already taken care of supporting 64-bit lengths, now we just need
to read it off the wire.
Note that this implementation will block indefinitely on a
Although extended mode is not yet enabled, once we do turn it on, we
need to reply with extended headers to all messages. Update the low
level entry points necessary so that all other callers automatically
get the right header based on the current mode.
Signed-off-by: Eric Blake
Reviewed-by:
Instead of ignoring the low-level error just to refabricate our own
message to pass to the caller, we can just plumb the caller's errp
down to the low level.
Signed-off-by: Eric Blake
---
v5: set errp on more failure cases [Vladimir], typo fix
v4: new patch [Vladimir]
---
block/nbd.c | 18
On 23.09.23 19:37, Laszlo Ersek wrote:
On 9/22/23 16:47, Lee Garrett wrote:
On 22.09.23 14:54, Richard W.M. Jones wrote:
On Fri, Sep 22, 2023 at 11:40:03AM +0100, Richard W.M. Jones wrote:
On Thu, Sep 21, 2023 at 07:47:52PM +0200, Lee Garrett wrote:
On 21.09.23 19:43, Richard W.M. Jones
I read the first email, you don't need to keep sending it.
If you upgrade RHEL from 8.2 to the latest (8.8 or 8.9) you
will get libguestfs 1.44.0.
If you upgrade to RHEL 9 you will get libguestfs 1.50.1.
Since you have (still) not described the exact environment you're
using, or even
Hi Richard,
Yes, you are correct my ask is without upgrading OS version(from 8.2 to 9.0) is
it possible to upgrade libguestfs alone to different versions.
Thanks
Teja
-Original Message-
From: Richard W.M. Jones
Sent: Monday, September 25, 2023 2:36 PM
To: Teja Konapalli
Cc:
On Mon, Sep 25, 2023 at 09:09:32AM +, Teja Konapalli wrote:
> Hi Richard,
>
> Yes, you are correct my ask is without upgrading OS version(from 8.2
> to 9.0) is it possible to upgrade libguestfs alone to different
> versions.
No, that is not supported.
Rich.
> Teja
>
> -Original
On Mon, Sep 25, 2023 at 01:09:15PM +0200, Lee Garrett wrote:
> On 23.09.23 19:37, Laszlo Ersek wrote:
> >On 9/22/23 16:47, Lee Garrett wrote:
> >>On 22.09.23 14:54, Richard W.M. Jones wrote:
> >>>On Fri, Sep 22, 2023 at 11:40:03AM +0100, Richard W.M. Jones wrote:
> On Thu, Sep 21, 2023 at
On Mon, Sep 25, 2023 at 01:14:40PM +0100, Richard W.M. Jones wrote:
> On Mon, Sep 25, 2023 at 01:09:15PM +0200, Lee Garrett wrote:
> > On 23.09.23 19:37, Laszlo Ersek wrote:
> > >On 9/22/23 16:47, Lee Garrett wrote:
> > >>On 22.09.23 14:54, Richard W.M. Jones wrote:
> > >>>On Fri, Sep 22, 2023 at
On Mon, Sep 25, 2023 at 01:25:06PM +0100, Daniel P. Berrangé wrote:
> On Mon, Sep 25, 2023 at 01:14:40PM +0100, Richard W.M. Jones wrote:
> > On Mon, Sep 25, 2023 at 01:09:15PM +0200, Lee Garrett wrote:
> > > On 23.09.23 19:37, Laszlo Ersek wrote:
> > > >On 9/22/23 16:47, Lee Garrett wrote:
> > >
46 matches
Mail list logo
