Do 'virsh dumpxml (vmname)'
The image doesn't matter. What matters is the OS you chose when you
registered. If you take my image and register it as Windows, it will
emulate IDE.
On Oct 25, 2013 11:16 PM, "Mike Tutkowski" <mike.tutkow...@solidfire.com>
wrote:
> Yeah, I'm using the CentOS 6.3 image you gave me a while back.
>
> Is the DiskDef XML output to agent.log or should I explicitly put in a log
> statement for it.
>
> Thanks!
>
>
> On Fri, Oct 25, 2013 at 11:02 PM, Marcus Sorensen <shadow...@gmail.com>wrote:
>
>> Sounds like your disk definition is not using virtio-block. In this case
>> you wouldnt be able to hot attach either though. Can you paste the diskdef
>> XML? This would normally only happen if you used a template defined with an
>> older OS, like the default centos 5.5 or "other Linux" instead of "other
>> Linux PV". In those cases I think it emulates IDE, which can't be
>> hotswapped.
>> On Oct 25, 2013 10:05 PM, "Mike Tutkowski" <mike.tutkow...@solidfire.com>
>> wrote:
>>
>>> Hey Marcus,
>>>
>>> I've been running all sorts of tests today and just noticed one issue.
>>>
>>> When I have a disk attached and reset (not reboot) the VM, the VM comes
>>> up just fine.
>>>
>>> If I then try to detach the disk, I get the following error:
>>>
>>> com.cloud.utils.exception.CloudRuntimeException: Failed to detach
>>> volume: Vol-6 from VM: VM-KVM-1; org.libvirt.LibvirtException: unsupported
>>> configuration: This type of disk cannot be hot unplugged
>>>
>>> Normally I have no problem detaching a disk. Once I get into this state;
>>> however, I seem to be stuck with an attached disk.
>>>
>>> Any thoughts on this?
>>>
>>> Thanks
>>>
>>>
>>> On Fri, Oct 25, 2013 at 12:58 AM, Mike Tutkowski <
>>> mike.tutkow...@solidfire.com> wrote:
>>>
>>>> Excellent - thanks!
>>>>
>>>>
>>>> On Fri, Oct 25, 2013 at 12:10 AM, Marcus Sorensen
>>>> <shadow...@gmail.com>wrote:
>>>>
>>>>> tests passed with latest commit hash you sent.
>>>>>
>>>>> On Thu, Oct 24, 2013 at 10:10 PM, Mike Tutkowski
>>>>> <mike.tutkow...@solidfire.com> wrote:
>>>>> > Just playing around with this on XenServer now.
>>>>> >
>>>>> > When I stop a VM, XenCenter no longer shows the VM (i.e. it behaves
>>>>> like VMM
>>>>> > does when a VM is stopped).
>>>>> >
>>>>> >
>>>>> > On Thu, Oct 24, 2013 at 9:53 PM, Marcus Sorensen <
>>>>> shadow...@gmail.com>
>>>>> > wrote:
>>>>> >>
>>>>> >>
>>>>> >> On Oct 24, 2013 7:39 PM, "Mike Tutkowski" <
>>>>> mike.tutkow...@solidfire.com>
>>>>> >> wrote:
>>>>> >> >
>>>>> >> > But what happens when, say, XenServer crashes and knows about VMs
>>>>> it had
>>>>> >> > running before it crashed?
>>>>> >>
>>>>> >> Not sure what XenCenter does but I thought it would/could start
>>>>> them on
>>>>> >> other nodes.
>>>>> >> >
>>>>> >> > I guess I was thinking you meant that CS purposefully creates VMs
>>>>> on KVM
>>>>> >> > in such a fashion that KVM will not remember them in the event of
>>>>> a crash.
>>>>> >>
>>>>> >> You're right about that, you get what I mean. Its done since
>>>>> there's no
>>>>> >> central manager and it causes problems for each host to keep a
>>>>> local config.
>>>>> >> I meant that CS doesn't necessarily tell the other hypervisors to
>>>>> remember,
>>>>> >> per se. They just do because its working through a cluster manager
>>>>> and
>>>>> >> that's what they do.
>>>>> >>
>>>>> >> >
>>>>> >> >
>>>>> >> > On Thu, Oct 24, 2013 at 7:25 PM, Marcus Sorensen <
>>>>> shadow...@gmail.com>
>>>>> >> > wrote:
>>>>> >> >>
>>>>> >> >> I just mean that they're still visible on those platforms because
>>>>> >> >> they're being tracked by some central source outside of
>>>>> cloudstack.
>>>>> >> >> Cloudstack itself I don't think cares, it just manages the
>>>>> resources as it
>>>>> >> >> sees in ITs database. I don't really see it as cloudstack
>>>>> treating KVM
>>>>> >> >> differently, rather just KVM lacking a central authority or
>>>>> cluster manager.
>>>>> >> >>
>>>>> >> >> On Oct 24, 2013 7:19 PM, "Mike Tutkowski"
>>>>> >> >> <mike.tutkow...@solidfire.com> wrote:
>>>>> >> >>>
>>>>> >> >>> So, I guess the moral is CloudStack has KVM treat VMs
>>>>> ephemerally, but
>>>>> >> >>> we (you and I) don't know how CS has XenServer and VMware treat
>>>>> VMs.
>>>>> >> >>>
>>>>> >> >>> I plan to do some testing with XenServer and VMware in a bit,
>>>>> so I can
>>>>> >> >>> stop a VM and see if it remains visible in their GUIs.
>>>>> >> >>>
>>>>> >> >>>
>>>>> >> >>> On Thu, Oct 24, 2013 at 7:17 PM, Mike Tutkowski
>>>>> >> >>> <mike.tutkow...@solidfire.com> wrote:
>>>>> >> >>>>
>>>>> >> >>>> My guess is XenCenter gets info about stopped VMs from the
>>>>> XenServer
>>>>> >> >>>> hosts it logs in to. I don't think it maintains a DB like
>>>>> vCenter does.
>>>>> >> >>>>
>>>>> >> >>>>
>>>>> >> >>>> On Thu, Oct 24, 2013 at 7:15 PM, Mike Tutkowski
>>>>> >> >>>> <mike.tutkow...@solidfire.com> wrote:
>>>>> >> >>>>>
>>>>> >> >>>>> Actually, I don't know if XenCenter remembers the VMs per se
>>>>> or if
>>>>> >> >>>>> it gets that information from querying the XenServer hosts it
>>>>> has access to.
>>>>> >> >>>>>
>>>>> >> >>>>>
>>>>> >> >>>>> On Thu, Oct 24, 2013 at 7:14 PM, Mike Tutkowski
>>>>> >> >>>>> <mike.tutkow...@solidfire.com> wrote:
>>>>> >> >>>>>>
>>>>> >> >>>>>> No, it does allow you to do that. I wasn't sure what you
>>>>> meant by
>>>>> >> >>>>>> your comparison, but XenCenter does remember VMs as far as I
>>>>> know.
>>>>> >> >>>>>>
>>>>> >> >>>>>>
>>>>> >> >>>>>> On Thu, Oct 24, 2013 at 7:08 PM, Marcus Sorensen
>>>>> >> >>>>>> <shadow...@gmail.com> wrote:
>>>>> >> >>>>>>>
>>>>> >> >>>>>>> Oh, xencenter doesn't remember VMS and allow you to start
>>>>> one if
>>>>> >> >>>>>>> the host it was on is down? I haven't played with it in a
>>>>> year but I thought
>>>>> >> >>>>>>> it synced with each xen server.
>>>>> >> >>>>>>>
>>>>> >> >>>>>>> On Oct 24, 2013 7:06 PM, "Mike Tutkowski"
>>>>> >> >>>>>>> <mike.tutkow...@solidfire.com> wrote:
>>>>> >> >>>>>>>>
>>>>> >> >>>>>>>> Well...XenCenter is "just" the GUI (like VI Client is for
>>>>> >> >>>>>>>> vSphere). As far as I know, XenServer has no equivalent to
>>>>> vCenter Server.
>>>>> >> >>>>>>>>
>>>>> >> >>>>>>>>
>>>>> >> >>>>>>>> On Thu, Oct 24, 2013 at 6:52 PM, Marcus Sorensen
>>>>> >> >>>>>>>> <shadow...@gmail.com> wrote:
>>>>> >> >>>>>>>>>
>>>>> >> >>>>>>>>> That is probably true, but there is no xencenter or
>>>>> vsphere
>>>>> >> >>>>>>>>> equivalent for KVM, no central authority. Its cloudstack.
>>>>> >> >>>>>>>>>
>>>>> >> >>>>>>>>> On Oct 24, 2013 6:22 PM, "Mike Tutkowski"
>>>>> >> >>>>>>>>> <mike.tutkow...@solidfire.com> wrote:
>>>>> >> >>>>>>>>>>
>>>>> >> >>>>>>>>>> OK, thanks for that info, Marcus...I was not aware that
>>>>> >> >>>>>>>>>> CloudStack treated VMs ephemerally with KVM.
>>>>> >> >>>>>>>>>>
>>>>> >> >>>>>>>>>> I guess I should try to stop a VM on XenServer and ESX
>>>>> and see
>>>>> >> >>>>>>>>>> what happens. I was under the impression they remained
>>>>> accessible using
>>>>> >> >>>>>>>>>> XenCenter or VI Client, but perhaps I am wrong about
>>>>> that.
>>>>> >> >>>>>>>>>>
>>>>> >> >>>>>>>>>> Since my KVM VM's root disk was on local storage, I
>>>>> expected it
>>>>> >> >>>>>>>>>> to remain accessible in VMM after I had stopped it via
>>>>> CS.
>>>>> >> >>>>>>>>>>
>>>>> >> >>>>>>>>>>
>>>>> >> >>>>>>>>>> On Thu, Oct 24, 2013 at 6:16 PM, Marcus Sorensen
>>>>> >> >>>>>>>>>> <shadow...@gmail.com> wrote:
>>>>> >> >>>>>>>>>>>
>>>>> >> >>>>>>>>>>> Are you talking cloudstack VMS or your own? If a vm is
>>>>> >> >>>>>>>>>>> 'created' it is ephemeral, the definition will
>>>>> disappear when stopped. This
>>>>> >> >>>>>>>>>>> is what cloudstack does so that a KVM host that crashes
>>>>> or loses power won't
>>>>> >> >>>>>>>>>>> remember and try to start VMS that were previously on
>>>>> it (they are likely
>>>>> >> >>>>>>>>>>> running elsewhere now). However, for your desktop and
>>>>> your own VMS you
>>>>> >> >>>>>>>>>>> usually 'define' VMS, which saves the XML to a file and
>>>>> leaves them
>>>>> >> >>>>>>>>>>> persistent. I use vmm occasionally, but usually virsh,
>>>>> the CLI version. Both
>>>>> >> >>>>>>>>>>> just talk to libvirt.
>>>>> >> >>>>>>>>>>>
>>>>> >> >>>>>>>>>>> On Oct 24, 2013 6:08 PM, "Mike Tutkowski"
>>>>> >> >>>>>>>>>>> <mike.tutkow...@solidfire.com> wrote:
>>>>> >> >>>>>>>>>>>>
>>>>> >> >>>>>>>>>>>> Hey Marcus,
>>>>> >> >>>>>>>>>>>>
>>>>> >> >>>>>>>>>>>> I assume you use Virtual Machine Manager with KVM?
>>>>> >> >>>>>>>>>>>>
>>>>> >> >>>>>>>>>>>> I was wondering, is there a way when you stop a VM to
>>>>> have it
>>>>> >> >>>>>>>>>>>> not disappear from the GUI?
>>>>> >> >>>>>>>>>>>>
>>>>> >> >>>>>>>>>>>> In XenCenter and VI Client, stopped VMs just show up
>>>>> with a
>>>>> >> >>>>>>>>>>>> different icon, but are still easy to interact with.
>>>>> >> >>>>>>>>>>>>
>>>>> >> >>>>>>>>>>>> Thanks!
>>>>> >> >>>>>>>>>>>>
>>>>> >> >>>>>>>>>>>>
>>>>> >> >>>>>>>>>>>> On Thu, Oct 24, 2013 at 5:46 PM, Mike Tutkowski
>>>>> >> >>>>>>>>>>>> <mike.tutkow...@solidfire.com> wrote:
>>>>> >> >>>>>>>>>>>>>
>>>>> >> >>>>>>>>>>>>> Also, the way I determined if the attach/detach
>>>>> worked was
>>>>> >> >>>>>>>>>>>>> to use fdisk -l and see if the device was present or
>>>>> not in the hypervisor
>>>>> >> >>>>>>>>>>>>> and VM instance.
>>>>> >> >>>>>>>>>>>>>
>>>>> >> >>>>>>>>>>>>>
>>>>> >> >>>>>>>>>>>>> On Thu, Oct 24, 2013 at 5:42 PM, Mike Tutkowski
>>>>> >> >>>>>>>>>>>>> <mike.tutkow...@solidfire.com> wrote:
>>>>> >> >>>>>>>>>>>>>>
>>>>> >> >>>>>>>>>>>>>> Here are some of the tests I ran on this code:
>>>>> >> >>>>>>>>>>>>>>
>>>>> >> >>>>>>>>>>>>>> attach/detach/attach volume while VM is running:
>>>>> works
>>>>> >> >>>>>>>>>>>>>> volume attached while VM is running, then reboot:
>>>>> works
>>>>> >> >>>>>>>>>>>>>> volume attached while VM is running, then reset:
>>>>> works
>>>>> >> >>>>>>>>>>>>>> volume detached while VM is stopped, then start:
>>>>> works
>>>>> >> >>>>>>>>>>>>>> volume attached while VM is stopped, then start:
>>>>> works
>>>>> >> >>>>>>>>>>>>>> deleted VM with attached volume: works (volume goes
>>>>> into
>>>>> >> >>>>>>>>>>>>>> the attachable state after VM is expunged)
>>>>> >> >>>>>>>>>>>>>>
>>>>> >> >>>>>>>>>>>>>>
>>>>> >> >>>>>>>>>>>>>> On Thu, Oct 24, 2013 at 5:40 PM, Mike Tutkowski
>>>>> >> >>>>>>>>>>>>>> <mike.tutkow...@solidfire.com> wrote:
>>>>> >> >>>>>>>>>>>>>>>
>>>>> >> >>>>>>>>>>>>>>> By the way, in case you're looking at the diff and
>>>>> >> >>>>>>>>>>>>>>> wondering why I took out a StopCommand check and
>>>>> call to execute in
>>>>> >> >>>>>>>>>>>>>>> LibvirtComputingResource, there were two of them.
>>>>> >> >>>>>>>>>>>>>>>
>>>>> >> >>>>>>>>>>>>>>> - } else if (cmd instanceof StopCommand)
>>>>> {
>>>>> >> >>>>>>>>>>>>>>>
>>>>> >> >>>>>>>>>>>>>>> - return execute((StopCommand) cmd);
>>>>> >> >>>>>>>>>>>>>>>
>>>>> >> >>>>>>>>>>>>>>>
>>>>> >> >>>>>>>>>>>>>>>
>>>>> >> >>>>>>>>>>>>>>> On Thu, Oct 24, 2013 at 5:26 PM, Mike Tutkowski
>>>>> >> >>>>>>>>>>>>>>> <mike.tutkow...@solidfire.com> wrote:
>>>>> >> >>>>>>>>>>>>>>>>
>>>>> >> >>>>>>>>>>>>>>>> This is a newer link, Marcus:
>>>>> >> >>>>>>>>>>>>>>>>
>>>>> >> >>>>>>>>>>>>>>>>
>>>>> >> >>>>>>>>>>>>>>>>
>>>>> https://github.com/mike-tutkowski/incubator-cloudstack/commit/e84de7577ad38fea88d1492d4949672d1989889b
>>>>> >> >>>>>>>>>>>>>>>>
>>>>> >> >>>>>>>>>>>>>>>> I just rebased on top of master today.
>>>>> >> >>>>>>>>>>>>>>>>
>>>>> >> >>>>>>>>>>>>>>>>
>>>>> >> >>>>>>>>>>>>>>>> On Thu, Oct 24, 2013 at 3:46 PM, Mike Tutkowski
>>>>> >> >>>>>>>>>>>>>>>> <mike.tutkow...@solidfire.com> wrote:
>>>>> >> >>>>>>>>>>>>>>>>>
>>>>> >> >>>>>>>>>>>>>>>>> Hey Marcus,
>>>>> >> >>>>>>>>>>>>>>>>>
>>>>> >> >>>>>>>>>>>>>>>>> If you're interested in running the simulator
>>>>> against
>>>>> >> >>>>>>>>>>>>>>>>> your code + my code, I have it on GitHub here:
>>>>> >> >>>>>>>>>>>>>>>>>
>>>>> >> >>>>>>>>>>>>>>>>>
>>>>> >> >>>>>>>>>>>>>>>>>
>>>>> https://github.com/mike-tutkowski/incubator-cloudstack/commit/776f3eb9dda45745f43e6765b026d34fbc6be072
>>>>> >> >>>>>>>>>>>>>>>>>
>>>>> >> >>>>>>>>>>>>>>>>> Thanks!
>>>>> >> >>>>>>>>>>>>>>>>>
>>>>> >> >>>>>>>>>>>>>>>>>
>>>>> >> >>>>>>>>>>>>>>>>> On Wed, Oct 23, 2013 at 11:06 PM, Mike Tutkowski
>>>>> >> >>>>>>>>>>>>>>>>> <mike.tutkow...@solidfire.com> wrote:
>>>>> >> >>>>>>>>>>>>>>>>>>
>>>>> >> >>>>>>>>>>>>>>>>>> I'm trying to attach my diff to
>>>>> >> >>>>>>>>>>>>>>>>>> https://reviews.apache.org/r/13865/, but I
>>>>> don't see the necessary buttons.
>>>>> >> >>>>>>>>>>>>>>>>>>
>>>>> >> >>>>>>>>>>>>>>>>>> I wonder if I need to get edit access back
>>>>> again? We
>>>>> >> >>>>>>>>>>>>>>>>>> had trouble with the Wiki. Was this also
>>>>> impacted?
>>>>> >> >>>>>>>>>>>>>>>>>>
>>>>> >> >>>>>>>>>>>>>>>>>>
>>>>> >> >>>>>>>>>>>>>>>>>> On Wed, Oct 23, 2013 at 10:47 PM, Mike Tutkowski
>>>>> >> >>>>>>>>>>>>>>>>>> <mike.tutkow...@solidfire.com> wrote:
>>>>> >> >>>>>>>>>>>>>>>>>>>
>>>>> >> >>>>>>>>>>>>>>>>>>> Sure, I can create a diff file and attach it to
>>>>> Review
>>>>> >> >>>>>>>>>>>>>>>>>>> Board.
>>>>> >> >>>>>>>>>>>>>>>>>>>
>>>>> >> >>>>>>>>>>>>>>>>>>>
>>>>> >> >>>>>>>>>>>>>>>>>>> On Wed, Oct 23, 2013 at 10:40 PM, Marcus
>>>>> Sorensen
>>>>> >> >>>>>>>>>>>>>>>>>>> <shadow...@gmail.com> wrote:
>>>>> >> >>>>>>>>>>>>>>>>>>>>
>>>>> >> >>>>>>>>>>>>>>>>>>>> Sure. The majority of it only affects people
>>>>> who are
>>>>> >> >>>>>>>>>>>>>>>>>>>> on your storage
>>>>> >> >>>>>>>>>>>>>>>>>>>> anyway. Perhaps you can post a patch and I can
>>>>> run it
>>>>> >> >>>>>>>>>>>>>>>>>>>> through the
>>>>> >> >>>>>>>>>>>>>>>>>>>> simulator to verify that the minor change to
>>>>> the
>>>>> >> >>>>>>>>>>>>>>>>>>>> existing code hasn't
>>>>> >> >>>>>>>>>>>>>>>>>>>> broken the standard storages. I don't think it
>>>>> is
>>>>> >> >>>>>>>>>>>>>>>>>>>> since I've
>>>>> >> >>>>>>>>>>>>>>>>>>>> thoroughly tested the code I posted, but I
>>>>> know there
>>>>> >> >>>>>>>>>>>>>>>>>>>> were some
>>>>> >> >>>>>>>>>>>>>>>>>>>> additional changes.
>>>>> >> >>>>>>>>>>>>>>>>>>>>
>>>>> >> >>>>>>>>>>>>>>>>>>>> On Wed, Oct 23, 2013 at 10:35 PM, Mike
>>>>> Tutkowski
>>>>> >> >>>>>>>>>>>>>>>>>>>> <mike.tutkow...@solidfire.com> wrote:
>>>>> >> >>>>>>>>>>>>>>>>>>>> > OK, Marcus, I made the change to detect my
>>>>> volumes
>>>>> >> >>>>>>>>>>>>>>>>>>>> > and it seems to work just
>>>>> >> >>>>>>>>>>>>>>>>>>>> > fine.
>>>>> >> >>>>>>>>>>>>>>>>>>>> >
>>>>> >> >>>>>>>>>>>>>>>>>>>> > Perhaps another day of testing and we can
>>>>> check
>>>>> >> >>>>>>>>>>>>>>>>>>>> > this code in. What do you
>>>>> >> >>>>>>>>>>>>>>>>>>>> > think?
>>>>> >> >>>>>>>>>>>>>>>>>>>> >
>>>>> >> >>>>>>>>>>>>>>>>>>>> >
>>>>> >> >>>>>>>>>>>>>>>>>>>> > On Wed, Oct 23, 2013 at 9:14 PM, Mike
>>>>> Tutkowski
>>>>> >> >>>>>>>>>>>>>>>>>>>> > <mike.tutkow...@solidfire.com> wrote:
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>
>>>>> >> >>>>>>>>>>>>>>>>>>>> >> Thanks, Marcus...I hadn't read that note,
>>>>> but that
>>>>> >> >>>>>>>>>>>>>>>>>>>> >> makes sense.
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>
>>>>> >> >>>>>>>>>>>>>>>>>>>> >> Yes, that must be the root disk for the VM.
>>>>> I can
>>>>> >> >>>>>>>>>>>>>>>>>>>> >> put in code, as you
>>>>> >> >>>>>>>>>>>>>>>>>>>> >> recommend, to handle only my volumes.
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>
>>>>> >> >>>>>>>>>>>>>>>>>>>> >> On Wed, Oct 23, 2013 at 5:37 PM, Marcus
>>>>> Sorensen
>>>>> >> >>>>>>>>>>>>>>>>>>>> >> <shadow...@gmail.com>
>>>>> >> >>>>>>>>>>>>>>>>>>>> >> wrote:
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>>
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> It should be sending the path info for
>>>>> each disk
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> per the XML of the
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> VM... so it will send all disks regardless
>>>>> of
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> whether or not your
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> adaptor manages that disk, and it's up to
>>>>> your
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> adaptor to ignore any
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> that aren't managed by it. There should be
>>>>> notes
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> to that effect in the
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> code near the disconnectPhysicalDisk
>>>>> interface in
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> StorageAdaptor:
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>>
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> // given local path to file/device (per
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> Libvirt XML), 1) check
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> that device is
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> // handled by your adaptor, return
>>>>> false if
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> not. 2) clean up
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> device, return true
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> public boolean
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> disconnectPhysicalDiskByPath(String
>>>>> localPath);
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>>
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> Since we only have XML disk definitions
>>>>> when we
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> stop or migrate a VM,
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> we have to try all adaptors against all
>>>>> defined
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> disks. So in your
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> disconnectPhysicalDisk you might do
>>>>> something
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> like check that the path
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> starts with '/dev/disk/by-path' and
>>>>> contains
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> 'iscs-iqn' (maybe there's
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> some way that's more robust like checking
>>>>> the
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> full path against a lun
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> listing or something). If it doesn't
>>>>> match, then
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> your
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> disconnectPhysicalDisk just does nothing.
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>>
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> I assume this is a root disk or some other
>>>>> local
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> storage disk. If it's
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> not, then your VM XML is messed up somehow.
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>>
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> On Wed, Oct 23, 2013 at 5:01 PM, Mike
>>>>> Tutkowski
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> <mike.tutkow...@solidfire.com> wrote:
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> > I found the problem.
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> > disconnectPhysicalDiskByPath is being
>>>>> passed in
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> > (in my situation) the
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> > following:
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >
>>>>> /var/lib/libvirt/images/9887d511-8dc7-4cb4-96f9-01230fe4bbb6
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> > Due to the name of the method, my code
>>>>> was
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> > expecting data such as the
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> > following:
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >
>>>>> /dev/disk/by-path/ip-192.168.233.10:3260-iscsi-iqn.2012-03.com.solidfire:volume1-lun-0
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> > Was it intentional to send the data into
>>>>> this
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> > method in the current
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> > way?
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> > On Wed, Oct 23, 2013 at 1:57 PM, Mike
>>>>> Tutkowski
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> > <mike.tutkow...@solidfire.com> wrote:
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >> You know, I forgot we supposed to be
>>>>> doing
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >> that! :) Multi-tasking too
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >> much
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >> today, I guess.
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >> Anyways, it must not be working because
>>>>> I
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >> still had a hypervisor
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >> connection after I shut down the VM.
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >> Let me investigate.
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >> On Wed, Oct 23, 2013 at 1:48 PM, Marcus
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >> Sorensen <shadow...@gmail.com>
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >> wrote:
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>> Are we not disconnecting when we stop
>>>>> the vm?
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>> There's a method for
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>> it, we
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>> should be.
>>>>> disconnectPhysicalDiskViaVmSpec
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>> On Oct 23, 2013 1:28 PM, "Mike
>>>>> Tutkowski"
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>> <mike.tutkow...@solidfire.com>
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>> wrote:
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> I see one problem for us now, Marcus.
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> * You have a running VM that you
>>>>> attach a
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> volume to.
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> * You stop the VM.
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> * You detach the volume.
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> * You start up the VM.
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> The VM will not be connected to the
>>>>> volume
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> (which is good), but the
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> hypervisor will still be connected to
>>>>> the
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> volume.
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> It would be great if we actually sent
>>>>> a
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> command to the last host ID
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> of
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> the stopped VM when detaching a
>>>>> volume (to
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> have the hypervisor
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> disconnect
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> from the volume).
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> What do you think about that?
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> On Wed, Oct 23, 2013 at 1:15 PM, Mike
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> Tutkowski
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>> <mike.tutkow...@solidfire.com> wrote:
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>> OK, whatever way you prefer then,
>>>>> Marcus
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>> (createVdb first or
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>> second).
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>> If I leave createVdb first and
>>>>> return 0, it
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>> does seem to work.
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>> On Wed, Oct 23, 2013 at 11:13 AM,
>>>>> Marcus
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>> Sorensen
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>> <shadow...@gmail.com>
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>> wrote:
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>>
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> I think we could flip-flop these
>>>>> two lines
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> if necessary:
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>>
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> createVbd(conn, vmSpec,
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> vmName, vm);
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>>
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>>
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>>
>>>>> _storagePoolMgr.connectPhysicalDisksViaVmSpec(vmSpec);
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>>
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> I haven't actually tried it though.
>>>>> But in
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> general I don't see the
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> Libvirt DiskDef using size at all,
>>>>> which
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> is what createVbd does
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> (creates XML definitions for disks
>>>>> to
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> attach to the VM
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> definition). It
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> just takes the device at it's native
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> advertised size when it
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> actually
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> goes to use it.
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>>
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> On Wed, Oct 23, 2013 at 10:52 AM,
>>>>> Mike
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> Tutkowski
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> <mike.tutkow...@solidfire.com>
>>>>> wrote:
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > Little problem that I wanted to
>>>>> get your
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > take on, Marcus.
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > When a VM is being started, we
>>>>> call
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > createVdb before calling
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > connectPhysicalDisksViaVmSpec.
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > The problem is that createVdb
>>>>> calls
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > getPhysicalDisk and my
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > volume
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > has not
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > yet been connected because
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > connectPhysicalDisksViaVmSpec has
>>>>> not
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > yet
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > been
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > called.
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > When I try to read up the size of
>>>>> the
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > disk to populate a
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > PhysicalDisk, I get
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > an error, of course, because the
>>>>> path
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > does not yet exist.
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > I could populate a 0 for the size
>>>>> of the
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > physical disk and then
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > the
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > next
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > time getPhysicalDisk is called, it
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > should be filled in with a
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > proper
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > size.
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > Do you see a problem with that
>>>>> approach?
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > On Tue, Oct 22, 2013 at 6:40 PM,
>>>>> Marcus
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > Sorensen
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > <shadow...@gmail.com>
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> > wrote:
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >> That's right. All should be well.
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >> On Oct 22, 2013 6:03 PM, "Mike
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >> Tutkowski"
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >> <mike.tutkow...@solidfire.com>
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >> wrote:
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> Looks like we disconnect
>>>>> physical
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> disks when the VM is
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> stopped.
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> I didn't see that before.
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> I suppose that means the disks
>>>>> are
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> physically disconnected
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> when
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> the VM is
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> stopped, but the CloudStack DB
>>>>> still
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> has the VM associated
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> with
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> the disks
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> for the next time the VM may be
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> started up (unless someone
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> does a
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> disconnect
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> while the VM is in the Stopped
>>>>> State).
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> On Tue, Oct 22, 2013 at 4:19
>>>>> PM, Mike
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> Tutkowski
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>> <mike.tutkow...@solidfire.com>
>>>>> wrote:
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> Hey Marcus,
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> Quick question for you related
>>>>> to
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> attaching/detaching volumes
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> when the
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> VM is in the Stopped State.
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> If I detach a volume from a VM
>>>>> that
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> is in the Stopped State,
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> the
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> DB
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> seems to get updated, but I
>>>>> don't see
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> a command going to the
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> KVM
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> hypervisor
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> that leads to the removal of
>>>>> the
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> iSCSI target.
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> It seems the iSCSI target is
>>>>> only
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> removed the next time the
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> VM is
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> started.
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> Do you know if this is true?
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> If it is, I'm concerned that
>>>>> the
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> volume could be attached to
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> another VM
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> before the Stopped VM is
>>>>> re-started
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> and when the Stopped VM
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> gets
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> restarted
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> that it would disconnect the
>>>>> iSCSI
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> volume from underneath the
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> VM
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> that now
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> has the volume attached.
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> I still want to perform some
>>>>> tests on
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> this, but am first
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> trying
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> to get a
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> VM to start after I've
>>>>> attached a
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> volume to it when it was in
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> the
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> Stopped
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> State.
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> Thanks,
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> Mike
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> On Mon, Oct 21, 2013 at 10:57
>>>>> PM,
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> Mike Tutkowski
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>> <mike.tutkow...@solidfire.com>
>>>>> wrote:
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> Thanks for that info, Marcus.
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> By the way, I wanted to see
>>>>> if I
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> could attach my volume to a
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> VM
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> in the
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> Stopped State.
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> The attach logic didn't
>>>>> trigger any
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> exceptions; however,
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> when I
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> started
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> the VM, I received an
>>>>> Insufficient
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> Capacity exception.
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> If I detach the volume and
>>>>> then
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> start the VM, the VM starts
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> just
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> fine.
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> I noticed a problem here (in
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> StoragePoolHostDaoImpl):
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> @Override
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> public StoragePoolHostVO
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> findByPoolHost(long poolId,
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> long
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> hostId) {
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>>> SearchCriteria<StoragePoolHostVO> sc =
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> PoolHostSearch.create();
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>>> sc.setParameters("pool_id",
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> poolId);
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>>> sc.setParameters("host_id",
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> hostId);
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> return
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> findOneIncludingRemovedBy(sc);
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> }
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> The findOneIncludingRemovedBy
>>>>> method
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> returns null (the
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> poolId is
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> my
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> storage pool's ID and the
>>>>> hostId is
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> the expected host ID).
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> I'm not sure what this method
>>>>> is
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> trying to do.
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> I looked in the
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> storage_pool_host_ref table
>>>>> (is that the
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> correct
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> table?) and it only has one
>>>>> row,
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> which maps the local
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> storage
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> pool of the
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> KVM host to the KVM host
>>>>> (which
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> explains why no match is
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> found
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> for my
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> situation).
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> Do you understand what this
>>>>> logic is
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> trying to do?
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> Thanks!
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> On Mon, Oct 21, 2013 at 8:08
>>>>> PM,
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> Marcus Sorensen
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> <shadow...@gmail.com>
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>> wrote:
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>>
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> Do you have the capability
>>>>> to clone
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> the root disk? Normally
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> the
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> template is installed to
>>>>> primary,
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> and then cloned for each
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> root
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> disk.
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> In some cases (such as
>>>>> CLVM), this
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> isn't efficient and so
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> the
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> template
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> is copied fresh to populate
>>>>> each
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> root disk.
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>>
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> I'm actually not 100% sure
>>>>> how this
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> works in the new code.
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> It
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> used to
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> be handled by
>>>>> copyPhysicalDisk in
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> the storage adaptor,
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> called
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> by
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>>
>>>>> copyTemplateToPrimaryStorage, which
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> runs on the agent. It
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> would
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> pass
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> template/secondary storage
>>>>> info,
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> and the destination
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> volume/primary
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> storage info, and
>>>>> copyPhysicalDisk
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> would do the work of
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> installing the
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> image to the destination.
>>>>> Then
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> subsequent root disks would
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> be
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> cloned
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> in CreateCommand by calling
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> createDiskFromTemplate.
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>>
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> In master it looks like this
>>>>> was
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> moved to
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> KVMStorageProcessor
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>>
>>>>> 'cloneVolumeFromBaseTemplate',
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> although I think this just
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> takes
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> over
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> as default, and there's
>>>>> something
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> in your storage driver
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> that
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> should
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> be capable of cloning
>>>>> templates on
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> the mgmt server side.
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> I'm
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> less sure
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> about how the template gets
>>>>> to
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> primary storage in the first
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> place, I
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> assume
>>>>> copyTemplateToPrimaryStorage
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> in KVMStorageProcessor
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> calling
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> copyPhysicalDisk in your
>>>>> adaptor.
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> It's a bit tough for me
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> to
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> tell
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> since our earlier storage
>>>>> adaptor
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> did everything on the
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> host it
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> mostly
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> just worked with the default
>>>>> stuff.
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>>
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> On Mon, Oct 21, 2013 at 4:49
>>>>> PM,
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> Mike Tutkowski
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> <
>>>>> mike.tutkow...@solidfire.com>
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> wrote:
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > Hey Marcus,
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > So...now that this works
>>>>> well for
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > data disks, I was
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > wondering
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > what
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > might be
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > involved in getting this
>>>>> process
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > to work for root disks.
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> >
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > Can you point me in the
>>>>> right
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > direction as far as what
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > gets
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > invoked
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > when a
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > VM is being created on KVM
>>>>> (so
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > that its root disk can be
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > created and
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > the
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > necessary template laid
>>>>> down or
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>> > ISO installed)?
>>>>> >> >>>>>>>>>>>>>>>>>>>> >>> >>>>>> >>>>>>
>>>>>
>>>> ...
