Seann,
If this happens again, try doing nothing (seriously) Each time I've had a
power failure, the engine takes a really long time to come back up. I
don't know if it's by design or what. Host logs are flooded with errors,
everything seemingly storage related. However, my Gluster setup is on
Command line.
I first did the import, then checked the image with 'qemu-img info' and
verified that the size was wrong and then copied, making sure to use the
same filename generated by the import.
On 3/30/21 1:35 PM, miguel.gar...@toshibagcs.com wrote:
I have the same problem, did you
I have the same problem, did you ovirwrite by copying through the GUI ?
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct:
I'm slowly getting things back up, but I ran into a perplexing network
problem.
I created a new vNIC profile in the engine web UI and attached it to the
hosted engine to test it, which in retrospect was not a good idea. I
realized that I needed to change something in the parameters of the
>
> That's what I figured, I'll look at the log files to see if I spot anything.
> Is
> there a way to do it from command line on the server ? Sometimes it's easier
> to spot
> issues from command line.
>
OK, so I cheated: I copied the image from backup to the current storage
overwriting the
> On Tue, Mar 30, 2021 at 12:55:36PM -, Valerio Luccio wrote:
>
> Ok, I understand now.
>
>
> In the VM edit dialog if you choose to Attach a disk the list contains
> column with checkboxes denoted 'OS'. Alternatively if you use Create or
> Edit action there are checkboxes on the right hand
On Tue, Mar 30, 2021 at 02:19:22PM -, Valerio Luccio wrote:
> I might have some more details, but I don't know what it means.
>
> When I do 'qemu-img info' on the VM image in backup I get:
>
> file format: raw
> virtual size: 128 GiB (137438953472 bytes)
> disk size: 128 GiB
>
>
On Tue, Mar 30, 2021 at 12:55:36PM -, Valerio Luccio wrote:
> > On Mon, Mar 29, 2021 at 09:03:41PM -, valerio.luccio(a)nyu.edu wrote:
> >
> > This does not seem right. The whole idea behind disk upload is that you
> > can do that remotely from any machine that has access to the REST API.
I might have some more details, but I don't know what it means.
When I do 'qemu-img info' on the VM image in backup I get:
file format: raw
virtual size: 128 GiB (137438953472 bytes)
disk size: 128 GiB
When I do the same on the VM image that was copied to the new storage I get:
> I do "Upload Image" and then hit "Chose File", the file selector opens
> up on my laptop, which does not have access to the gluster storage.
I did "Test Connection" in the "Upload Image" window and it works.
>
> Sorry, where do you mark a disk to be bootable ? I didn't notice any such
>
> On Mon, Mar 29, 2021 at 09:03:41PM -, valerio.luccio(a)nyu.edu wrote:
>
> This does not seem right. The whole idea behind disk upload is that you
> can do that remotely from any machine that has access to the REST API.
> If this is not working for you (but works when performed from the
>
On Mon, Mar 29, 2021 at 09:03:41PM -, valerio.luc...@nyu.edu wrote:
> Kind of ...
>
> First I had to run remotely a browser on the server, the only way to upload
> files on the storage attached to it.
This does not seem right. The whole idea behind disk upload is that you
can do that
> On 29. 3. 2021, at 14:43, Roman Bednar wrote:
>
> Hi Andrei,
>
> kvm64 is a legacy type, not recommended for use by qemu project [1]. I
> suppose that's the reason it's been left out from the list you're looking at.
we only include ~10 years old CPUs, anything older is usually not useful
Hi Seann,
On Mon, Mar 29, 2021 at 8:31 PM Seann G. Clark via Users
wrote:
> All,
>
>
>
> After a power failure, and generator failure I lost my cluster, and the
> Hosted engine refused to restart after power was restored. I would expect,
> once storage comes up that the hosted engine comes
14 matches
Mail list logo