10:01 a.m.
This is a multi-part message in MIME format.
--------------080701090401070704010104
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
I have a couple ESXi Win 7 images on VMDKs that I converted to raw using
qemu-img convert.
Under ovirt 3.3.1 I then used a procedure posted here previously where
you create a VM, add a disk, then copy over the converted image onto the
oVirt created image and away you go.
I did this twice under oVirt 3.3.1 and it worked great.
Now I have built a new oVirt 3.3.2 system and tried the same thing, and
I get the error:
VM win7-01 is down. Exit message: Bad volume specification {'index': 0,
'iface': 'virtio', 'reqsize': '0', 'format':
'raw', 'bootOrder': '1',
'volumeID': 'd750e9e0-a906-4369-8bbb-a3b676121321',
'apparentsize':
'107374182400', 'imageID': 'f674cb27-c28b-4373-ad75-9ed8a765ca31',
'specParams': {}, 'readonly': 'false', 'domainID':
'f14f471e-0cce-414d-af57-779eeb88c97a', 'optional': 'false',
'deviceId':
'f674cb27-c28b-4373-ad75-9ed8a765ca31', 'truesize':
'107374194688',
'poolID': '18f6234c-a9de-4fdf-bd9a-2bd90b9f33f9', 'device':
'disk',
'shared': 'false', 'propagateErrors': 'off',
'type': 'disk'}.
The original oVirt 3.3.1 system that has now been upgraded to 3.3.2
still boots this same disk image just fine.
I'm guessing it's upset because apparentsize and truesize are different?
Why did 3.3.1 seem not to care but 3.3.2 does now?
Any way I can true these up? I've tried a few things with qemu-img but
haven't gotten the magic right yet.
--------------080701090401070704010104
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
</head>
<body bgcolor="#FFFFFF" text="#000000">
I have a couple ESXi Win 7 images on VMDKs that I converted to raw
using qemu-img convert. <br>
<br>
Under ovirt 3.3.1 I then used a procedure posted here previously
where you create a VM, add a disk, then copy over the converted
image onto the oVirt created image and away you go.<br>
<br>
I did this twice under oVirt 3.3.1 and it worked great.<br>
<br>
Now I have built a new oVirt 3.3.2 system and tried the same thing,
and I get the error:<br>
<br>
<div title="VM win7-01 is down. Exit message: Bad volume
specification {'index': 0, 'iface': 'virtio',
'reqsize': '0',
'format': 'raw', 'bootOrder': '1',
'volumeID':
'd750e9e0-a906-4369-8bbb-a3b676121321', 'apparentsize':
'107374182400', 'imageID':
'f674cb27-c28b-4373-ad75-9ed8a765ca31',
'specParams': {}, 'readonly': 'false', 'domainID':
'f14f471e-0cce-414d-af57-779eeb88c97a', 'optional':
'false',
'deviceId': 'f674cb27-c28b-4373-ad75-9ed8a765ca31',
'truesize':
'107374194688', 'poolID':
'18f6234c-a9de-4fdf-bd9a-2bd90b9f33f9',
'device': 'disk', 'shared': 'false',
'propagateErrors': 'off',
'type': 'disk'}." tabindex="0"
style="outline-style: none;"
__gwt_cell="cell-gwt-uid-73812">
<div id="gwt-uid-3412_col2_row4">VM win7-01 is down. Exit message:
Bad volume specification {'index': 0, 'iface': 'virtio',
'reqsize': '0', 'format': 'raw',
'bootOrder': '1', 'volumeID':
'd750e9e0-a906-4369-8bbb-a3b676121321', 'apparentsize':
'107374182400', 'imageID':
'f674cb27-c28b-4373-ad75-9ed8a765ca31', 'specParams': {},
'readonly': 'false', 'domainID':
'f14f471e-0cce-414d-af57-779eeb88c97a', 'optional':
'false',
'deviceId': 'f674cb27-c28b-4373-ad75-9ed8a765ca31',
'truesize':
'107374194688', 'poolID':
'18f6234c-a9de-4fdf-bd9a-2bd90b9f33f9', 'device': 'disk',
'shared': 'false', 'propagateErrors': 'off',
'type': 'disk'}.</div>
</div>
<br>
The original oVirt 3.3.1 system that has now been upgraded to 3.3.2
still boots this same disk image just fine.<br>
<br>
I'm guessing it's upset because apparentsize and truesize are
different?<br>
<br>
Why did 3.3.1 seem not to care but 3.3.2 does now?<br>
<br>
Any way I can true these up? I've tried a few things with qemu-img
but haven't gotten the magic right yet.<br>
<br>
<br>
<br>
<br>
</body>
</html>
--------------080701090401070704010104--
10:10 a.m.
On Wed, Jan 08, 2014 at 10:01:13AM -0600, Blaster wrote:
No quick answer pops to mind. Could you share your vdsm.log from the
vmCreate line up until the error you have quoted?
Any way I can true these up? I've tried a few things with qemu-img
but haven't gotten the magic right yet.
12:46 p.m.
--Apple-Mail=_AAEE13C0-B640-41DB-9751-0B4AC8094F2E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=windows-1252
On Jan 8, 2014, at 10:10 AM, Dan Kenigsberg <danken(a)redhat.com> wrote:
I figured it out. The disk image permissions didn=92t copy over, so =
vdsm couldn=92t read the disk image..
Thanks for the response.=
--Apple-Mail=_AAEE13C0-B640-41DB-9751-0B4AC8094F2E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=windows-1252
<html><head><meta http-equiv=3D"Content-Type"
content=3D"text/html =
charset=3Dwindows-1252"></head><body style=3D"word-wrap: break-word;
=
-webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space;"><br><div><div>On Jan 8, 2014, at 10:10 AM,
Dan =
Kenigsberg <<a =
href=3D"mailto:danken@redhat.com">danken@redhat.com</a>> =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote
=
type=3D"cite"><div style=3D"font-size: 12px; font-style: normal; =
font-variant: normal; font-weight: normal; letter-spacing: normal; =
line-height: normal; orphans: auto; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; widows: auto; word-spacing: =
0px; -webkit-text-stroke-width: 0px;"><br>No quick answer pops to mind. =
Could you share your vdsm.log from the<br>vmCreate line up until the =
error you have quoted?<br><br></div></blockquote></div>I
figured it out. =
The disk image permissions didn=92t copy over, so vdsm couldn=92t =
read the disk image..<div><br></div><div>Thanks for the =
response.</div></body></html>=
--Apple-Mail=_AAEE13C0-B640-41DB-9751-0B4AC8094F2E--
4202
days inactive
4202
days old
2 comments
3 participants
participants (3)
-
Blaster -
Blaster
-
Dan Kenigsberg